Hi all,
Well, this discussion has been great fun :-\ , but getting back to the
original point......
The original poster said that using zero for NULL raised issues on the
MSP430, as there is actually something at zero (at least, I think that
was their intent). However, nobody has yet identified any real problems
this casues. The thing at zero is a register, which one would not
normally access by pointer. Some other registers, like the port
registers, might be accessed by pointer and offset. It has merit there,
since each port has a similar register group. The register at zero isn't
like that, though, and I can't imagine any cause for using a pointer to it.
Can anyone raise any real issues with NULL being zero? Changing it now
would be a big pain, and would make mspgcc incompatible with a lot of
code produced for other MCU C compilers.
Regards,
Steve
nobo...@web.de wrote:
Hi,
mspgcc-users@lists.sourceforge.net schrieb am 30.03.04 16:13:52:
Kernighan and Ritchie assumed that every computer knows the number zero.
This is the only value the C language uses.
Using NULL with a value of 42,
- is not portable, a 4bit micro controller doesn't known 42. ;-)
that's wrong, because the value of NULL is implementation defined and on some
machines the value of NULL is not 0 (see C-FAQs).
If you have code which needs NULL to be (arithmetic) 0 you have a code which is
not portable and you are casting to/from pointer type from/to artithmetic type.
And on the target platform the value of NULL is irrelevant; the program has
only to behave standard conform.
- It is gives problems if you use the NULL as FALSE.
You are mixing bool types and pointer types. It's like adding apples and
bananas.
- It produces more code.
No. Why should there be more or less code?
- It is not C
Look into the C standard (www.ansi.org) and C-FAQs.
Rolf
