> > > BTW, I've seen processors where char is 32 bit. > > The storage allocation of a char may be 16-bits, 32-bits or whatever, with > only 8-bits actually being used.
A "char" is always at least the size of the smallest allocation unit for the architecture. So for a dsp with 16-bit or 32-bit chars, a "char" is 16-bit or 32-bit wide and you can use all these bits. > However the ANSI definition of sizeof(char) is that it always returns 1. > This can lead to nasty problems if you say malloc N bytes to hold N chars > .... even if you try to be decent and use sizeof(char) when calling the > malloc! > No, malloc() allocates char-units, not bytes (Ansi C does not mention "bytes" much at all, since there is no requirement for "byte" to be 8 bits. It occasionally mentions "octets".) The problems occur when you have a dsp with 16-bit chars and 16-bit ints, and think that to allocate space for 10 ints you use malloc(20) - when you should use malloc(10*sizeof(int)). So using sizeof is exactly the right practice. Of course, I'd double check that the compiler/library is really doing what you want! > Even worse: if you allocate RAM for some chars, where the char is say > 32-bits, and then zero the bottom 8-bits ... but the top 24-bits are filled > with junk, then checking the char against 0 can fail, because a 32-bit > instruction might be used. This sounds like a pretty wierd and non-conforming compiler - even the wierd and non-conforming 16-bit DSP compiler I've used was not that bad. Typically in this case, the cpu can't write 8-bit data - it has to write the whole 16-bit or 32-bit (which is why it has big chars in the first place). To write 0 in the bottom 8-bits, while keeping junk in the rest, requires a lot of extra effort. My experiance, which I believe is in keeping with the standard, is that "char c = 0" makes a char variable and sets *all* its bits to 0. > > This nastiness has only caught me out with certain DSPs which have limited > support for byte sized data. > > regards, > > Richard > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > >
