> You've got two smilies and a grin here, so you're probably just joking > abotu the whole thing, but still...
:) > While this would certainly work, it's the first time I've seen this idea > used this way, and my intuition rings alarm bells. Would NUL match against > type restrictions that expect a (void *)NULL? most compilers dont care about (void *)NULL and NUL :) i guess it has been hacked into the compiler to say "well, its obvious, we know what we will do".. keep in mine, (void *) = is a dword containing 0. so, assigning it to a byte, will truncate it anyhow. if you turn on strict warnings, it'll complain (ie: in C++) > Maybe or maybe not depending on the compiler, but why be ambiguous at > all? When you're talking about trailing spaces at the end of a string, > why not *always* type: > > str[index] = '\0'; > > If you're talking about integers, why not always: > > myInts[index] = 0; well, mainly cause an integer array doesn't have a "null terminator" C strings require a '\0' character on the end to mark the end of the string :) you dont deal with integer arrays in the same way :) > Every C programmer will have seen, dealt with, and learned what these > lines mean. Which means no ambiguities and hopefully fewer bugs. welcome to C :) great language isn't it? :P --- Aaron Ardiri [EMAIL PROTECTED] CEO - CTO +46 70 656 1143 Mobile Wizardry http://www.mobilewizardry.com/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
