I think that calling C "portable assembly" is really a bit untrue. One of the core features of most any machine language is that flags are part of the result of many computing operations. Yet C completely removes access to it.

Suppose you have a code that adds two things, then jumps on overflow. On most machines that's two instructions if the operands have the right size. You look at it, and the intent is obvious: we add, then jump on overflow.

Things are seriously wrong (IMHO) if a higher level language completely obfuscates this and requires code where it's not obvious at all what you mean! Heck, what's worse, each compiler likely requires slightly different code so that the meaning is extracted by the optimizer and the correct assembly output is produced without paying both code size and performance penalties! In C, the best you can do on a good compiler is to have an inlineable function that returns the numerical part of the result, uses comparisons to "recreate" the detection of overflow, and returns the overflow condition in a char* out-parameter. If the optimizer is good, it'll recognize that the out parameter accesses an automatic variable in the caller, and that your comparison is just checking for overflow. This code, while portable C, will perform horribly as soon as you compile it without state-of-the-art optimization capabilities. I'd think that means that if your compiler wasn't released in the last year or two, and isn't a mainstream decently optimizing one (like gcc, llvm, visual studio), you're out of luck. On many platforms a saturating increment/decrement is also two or three assembly instructions at most, without jumps -- but good luck getting a compiler to actually emit such code.

I think that providing no way to access the flags part of arithmetic operation results is one of the biggest oversights in C. I'd think that every platform C runs on provides such flags.

This is perhaps the most informative thing I've read all day. Thanks!

So, nothing you'd care to run makeinfo on. Point taken. Er, what were you saying, again?

That's true of course.

Sweetheart, wasn't it the intelligent and money-smart German bankers buying lots of the junk paper that nobody in the U.S. would even touch with a long pole just before the recent housing bust? I think there was a few billion USD worth of that stuff that is being written off by the landesbanks all over the place. Slowly but surely. It got to a point where "boys from Stuttgart" were joked about here.

So, where's all the useful stuff he invented? Do I have any of that in my home? Do any of my neighbours do? Huh?

They'll soon have to pay people for such stories.

A camera? Now stop being silly. Go to a location that has presumedly similar layout to the one in question. Take a pic with your digital camera. Scale it down to NTSC resolution. That's the best case image you're going to get -- stuff from usual cameras used for monitoring looks much worse. Most security cameras are completely useless. You can barely tell between a human and a gorilla on most of the feeds that catch large areas. A small storefront may leave you with a bit better image than most, but it's still way too large area of an to cover if you want to see any faces. Other than recognizing faces, what's the point? I mean, you know there was a break-in, there's no reason to look at a video recording to confirm what's obvious. Either you get faces that are recognizable, or it's mostly useless.

You've basically fallen for the security monitoring scam: people love it until they actually need to see the images and realize they are useless.

To get good monitoring you need HD cameras, and plenty of them. For a small storefront monitoring, you may need coverage from two 1080p webcams. They are not exactly the most inexpensive of things. Alternatively, if you believe in a bit of luck, a digital photo camera taking timelapse pictures every second may also be likely to catch the faces. I'd go for one of the Canons where you can replace stock firmware with CHDK. You can then make it delete old pictures and keep new ones in round-robin fashion.

Yes, the experiment is the ultimate validation of any theory, but it needs to be done in such a way that sufficiently controls for things. Here, demonstrably, when you control for the solidity of the car and choose a solid car, you're not ripping anything out. I'm not surprised junk cars that the likely burglars drive would be, um, more prone to getting the rear end separated.

Exactly. It is due to those determined people that you don't want to be alerted instantly -- because you may just do something stupid like go there and get beaten up or shot.

To me it seems possible that it's a protection racket and they're not telling you that they've been asked for money. Maybe they just didn't get the hint.

Alas, but beware! Computer science != software engineering. Both aspects are important for a successful software developer. If you're in a computer science course of study in academia, I do expect you to be no better in software engineering side of things than a self-taught kid fresh out of the college. Same goes for those who only know the engineering side well, without grokking the mathematical theory.

Only because there was no API to achieve certain things. Only because of that. A built-in assembler and library calls to modify the stuff people usually peeked and poked for would remove 99% of peeks and pokes.

Huh? So obviously in those "higher level languages" you can trivially generate pointers that will let you overwrite your stack, or alias some variables the compiler presumes you'll not alias, or write past the end of the array (or before its beginning), etc? Because, you see, those are the problems that stuff in C and C++ runs into, never mind memory leaks and use of freed memory.

Because it's a language that's not really good for anything. It's widely used because there are no alternatives, not because it's particularly good. It wasn't really designed by people who had solid foundations of programming language design, and it wasn't designed to solve the particular problems that the web is facing in the long term. It has been kludged to work. Just look at how much effort it takes to efficiently JIT that thing. Lua's JIT is almost trivial in comparison, yet produces very decent code.

Legacy codesys-based industrial PLCs, where I evaluated LuaJit as a replacement, have arrays limited to 64 kbytes in size, even when targeting 32 bit Intel platforms. Whatever limitations LuaJIT has, save for 2.0 teething pains, are not even on my horizon :)