No. You just have to keep the charging device elevated above the charged device. It works like a siphon.

You're not supposed to, but you do routinely have software that has bugs even in aerospace, because there is no development process that can guarantee the prevention of 100% of defects, nor even guarantee that 100% of defects are detected and corrected.

That 9% is pretty used to having reduced access to licensed, live television content as a direct consequence of not paying a subscription for licensed, live television content.

You sound upset. Maybe go relax at a movie?

Well, I mean, if he shot him in the leg or something, he'd just be screaming through the whole movie.

Yeah, no shit. This is monstrous and so far beyond the pale. I'd say that we should be tazing texters, physically beating serial talkers, and reserving the instant death penalty for people who answer their cell phones.

You Won't Believe What Federal Marshals Did When They Caught Him!
12 Great Ways To Pass Your Extended Sentence
Think "Cool Hand Luke" Was Just a Movie? Think Again!

Dude, listen. I don't even know what you're trying to argue at this point, and to be honest, I don't really care. You don't understand C (or English!) well enough for me to get anything out of this conversation, which as far as I can tell, no longer has anything to do with anything besides your ego. The basic point -- that it is within the guidelines of the Standard for a C compiler to delete null checks on a pointer after it is guaranteed that said pointer has been dereferenced -- has been proved multiple times. Whatever fucking alcoholism or anger management or insecurity issues or whatever are leading you to ramble down this insane, incoherent road, I'll let you deal with on your own.

Where did I admit that I made an erroneous claim? Where did I MAKE an erroneous claim? Like, I was worried I would confuse you with all those words, but this is ludicrous. I never said GCC had this optimization by default -- only that it's Standards-legal to make that optimization, you dummy. Re-read the thread. You are very confused.

Now you're just using a very arbitrary definition of "broken." The compiler, in this specific instance, is working precisely as intended. It's not like someone accidentally went and implemented -fdelete-null-pointer-checks into GCC, Clang and MSVC and then everyone else went on accepting it without question. It's a concept with quite a bit of thought and care and discussion put into it.

The basic premise of an optimizing compiler is this: produce output that is at least as fast as the original code as-written and adheres to all defined behavior. In this case, it's spot-on -- the only way through the example function with defined behavior is to have a non-NULL pointer, in which case, the branch comparison is a waste of CPU cycles. For undefined behavior, the compiler has no obligations. All bets are off. You don't get to dereference NULL pointers, then complain that your program didn't work as expected, unless you're working with a compiler that honors obligations above and beyond the C standard.

There are some environments in which you DO want to have some say in what happens next -- which I guess in my opinion would be anywhere that dereferencing a NULL pointer is legal, or at the very least, not instantly and reliably fatal. Compiler authors have not forgotten about you. In GCC, for example, you have two options:
  1. Do not use -O2 or -O3
  2. Use -O2 or -O3 in conjunction with -fno-delete-null-pointer-checks, in which case, your null pointer checks will be left unmolested.

I know after a similar piece of code to the example was discovered in the Linux kernel, they decided to apply -fno-delete-null-pointer-checks. Not sure if that's still true.

A far more egregious example of a compiler exploiting undefined behavior is GCC 1.x which, when given invalid pragmas, would generate code that attempted to exec nethack, rogue, Emacs towers of hanoi, or failing all of those, just generate a printf making fun of you.

In conclusion... know thy optimizer. It's making decisions about your code that can affect you, and it is configured by default to cover the most common use cases. If your program depends on behaviors that are unusual and not covered by the standard (like being able to dereference a null pointer), then you should review your compiler's documentation and see if you need to tune the optimizer a bit for your use case. But if your standards-compliant compiler is applying a well-documented optimization in a manner that breaks you, then it's your project that's broken, either for using that optimization, or for relying on undefined behavior.

From your favorite FAQ and mine, comp.lang.c: (http://c-faq.com/ansi/undef.html):
"undefined: Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended. Note, too, that since the Standard imposes absolutely no requirements on the behavior of a compiler faced with an instance of undefined behavior, the compiler (more importantly, any generated code) can do absolutely anything."

In other words, once you do something whose behavior is undefined, you have a program whose execution is (at least, as far as the C standard on its own is concerned) unpredictable. Given that, the compiler can do almost anything it wants in situations where behavior is undefined. It could, for example, just abruptly terminate the program. That would make Chris's comment spot-on.

Alternatively, he could rewrite the comment as, // P was dereferenced by this point, so it is either non-NULL or the programmer's wishes and expectations no longer apply.

So yes, it is a completely legit optimization, in full accordance with the C standard, and if you REALLY want to be able to dereference a NULL and have some expectation about what your program does after that, then you need to choose your compilers and/or optimization settings carefully because the C standard alone is not going to give you what you want.

Yeah man if only the LLVM team thought to look at the C standard or consult with Slashdot commenter Zero__Kelvin

rolleyes

You're not really a very good programmer if this is your reaction to being proven wrong.

You really, really ought to read the link he gave you. It's quite eye-opening.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html

Uh, I think you need to re-read his post a little more carefully. This is getting a little embarrassing for you, and if you've been doing embedded development for 30 years and still don't know how optimizing compilers work, I feel REALLY bad for you. I can see why you're so insecure.

It sounds like you are a very passionate hobbyist, but one of the nice things about a forum like Slashdot is that there are a lot of professionals like EvanED who will offer you free advice. I suggest you start listening and stop biting the hand that feeds you! Who knows, Evan might have even made some of the software you're using right now. If you work and study hard and ask good questions (respectfully!) you might even be able to work on it with guys like him someday.