Simon Josefsson <[EMAIL PROTECTED]> writes:
> Is there a portability requirement that 'char foo = 0xAA' end
> up with 10101010 in the memory buffer (void*)&foo?
No for C, but yes for POSIX.
The main problem with char * is that, in principle, an implementation
can dump core if you do something like "char *p; ...; *p = 128;",
because 128 isn't a valid char value if char is signed. I don't know
of any practical implementations that crash, but some debugging
implementations might, and in some sense that's a good thing.
> I'm not sure about 'unsigned char*'. Using 'unsigned char*' usually
> lead to plenty of signed/unsigned warnings sooner or later.
Yes, I try to avoid 'unsigned char *' for that reason'. 'unsigned
char' is fine though. I generally do something like this if I want to
deal with values in the range 0 .. UCHAR_MAX:
char *p = ... compute with p ...;
unsigned char uc = *p;
... compute with uc ...
rather than use 'unsigned char *'. It's a little more verbose but
avoids the warnings and it's perfectly portable. The tricy part is
converting the unsigned char back to char. But I'm usually lazy and
just store it (e.g., "*p = uc"): that works on all the hosts I know
about.
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
