It is obvious if you know it is non-standard, probably not if you don't.
The best thing is simply not to do it, you rarely if ever need it unless
you are writing your own memory allocator.
I agree, but it doesn't hurt knowing it's possible (though not portable),
and knowing how things work.
Like everything else it is not dangerous on implementations where it
works, but could be disasterous on implementations where it doesn't. The
approach should always be to looks for approaches that avoid doing things
like this.
Yes, sir ! No irony, I completely agree it's not the style to use
too often, but if I remember well, the original post asked for
a manner to see what NULL is. Just a toy program after all.
Sometimes, it may be necessary: you mention a memory allocator,
but there may be other uses.
After all what if it breaks on the next version of the compiler
you use? There's nothing wrong with the compiler, it is the code that is
faulty.
Some parts of a program are by nature very dependent on OS/compiler/proc.
It's a good practice to try to avoid them, it's not good practice do
deny their existence. This newsgroup deny all that is not perfectly
described by the Standard. It's only this attitude I reject, not
the Standard itself.
I find that hard to believe. It suggests that you haven't put enough
thought into finding a better solution.
You are right, I must confess
If you link asm to C code you are sacrificing portability, which is fine
in some circumstances.
I agree (but do I need to say that ?
).
However you are (or should be) still basing the
code on specifications that define its behaviour. By doing things like
calling functions incorrectly you have NO specification of behaviour,
Well, the standard doesn't specify anything, but your knowledge of
the system you're programming on (including compiler), gives you
all needed informations on the behaviour. When in doubt, it's always (?)
possible to have a look at the assembly output.
you
are trusting to blind luck and hope that things will continue to work as
you have observed in the past.
Nope. I never trust a compiler
Even with beautiful C code, I'm not
confident in its optimizations, especially concerning floating point.
And this opinion is not going to change in the near future: "paranoia" is
old, but still an interesting test (just as an example).
This is no way to program. Today's compiler
optimisers are too complex to predict with any certainty.
Here I disagree. There are many predictable parts in gcc output, with enough
habit, you know when writing some code if it will be well optimized or not,
and which kind of optimization occurs. If you think your compiler is
perfect, well I hope it is ! Gcc, to stay with something I am acquainted
with, won't use prefetch or Altivec instructions (I heard gcc 4 will, but
I'm still not convinced). Hence it's not so difficult to beat its optimizer.
On the other hand, it's much more difficult to beat xlc (won't use Altivec,
but apart from that, it is very, very clever). I think a good practice is
always having a look at assembly output, for function that need good
optimizations, or that use non standard tricks. Obviously, that demands
some understanding of OS/proc.
Oh, and I said "acquainted with gcc", I wouldn't even try to make anyone
believe I know perfectly how it works.
You may use a
trick that worked many times, then one day with the same compiler you use
it in a situation which the compiler decides it can optimise and suddenly
the trick no longer works.
Not seen for the moment, but I am vigilant
There was an example of this in another
thread to do with overlaying structures.
I'll look for it !
One of the reasons C leaves some
areas of behaviour undefined is to allow more aggressive optimisations.
And why does many if not all compilers allow so many extensions ? Some are
completely understandable, but many (including gcc's extensions) are too
tempting, and when used, code is irremissibly struck with one specific
compiler. It may seem strange for me to say that
In fact I agree with
the principle of a standard (I've seen this necessity with these many
implementations of f77 hanging around), but I don't agree to deny specific
use of it, when it's needed. Only when it's needed. And I'm glad you
pointed out a good way to do what was asked in this thread. I hope I've
clarified some points.
By the way, is it completely portable ? Use of an array of chars to read
what is very often an integer may seem strange. It's fun: it's portable
only because the standard don't know a pointer is an int or
something else
Actually, we only want to know if NULL is 0, so no
problem.