Re: different struct sizes

jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:
Keith Thompson wrote:
richard@xxxxxxxxxxxxxxx (Richard Tobin) writes:

In article <lny7qoi6j1.fsf@xxxxxxxxxxxxxxx>,
Keith Thompson <kst-u@xxxxxxx> wrote:

sizeof(char) is 1 by definition, that doesn't mean that it's one byte

Yes, it certainly does; that's the C standar's definition of "byte".

Unfortunately any platform will have its own definition of byte, and
though these coincide 99.9% of the time, the difficult cases will be
the ones where it doesn't. The fact that something is true of C's
definition of byte is not very useful when the issue is how it maps
onto the implementation - you can't expect every word to be used with
C's definition in that context.
In this newsgroup, I can and I do expect words defined in the C
standard to be used in accordance with the way the C standard defines
them. Anyone using the word "byte" here in some other sense needs to
say so.
The statement was:
sizeof(char) is 1 by definition, that doesn't mean that it's one
byte
If the poster had said:
sizeof(char) is 1 by definition, that doesn't mean that it's one
byte
(as a particular platform defines the word "byte")
I would have had no objection.

Important distinction. When I ported lcc-win32 to a DSP, each
character took two bytes (16 bits) because the machine could not
address odd bytes. Still, sizeof(char) was 1 of course.

Yes, it's an important distinction, and you're blurring it.

Each character took *one* byte (16 bits). One byte happened to be two
octets.

In that environment sizeof(char) == sizeof(short) == sizeof(int).
Only longs were 32 bits.

Perfectly legal, of course. It could cause some interesting problems
with stdio, since it's difficult to distinguish between EOF and a
character that happens to have the same value. But a DSP would
presumably have a freestanding implementation, so stdio support isn't
required.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.

Relevant Pages

  • Re: porting issues ?
    ... Have you ever worked on a platform where CHAR_BIT was NOT 8? ... doing a lot of work on a TI 2812 DSP right now where CHAR_BIT is 16. ... significant bits an unsigned char and ignore anything else. ... The value of CHAR_BIT is not much of a deterrent to portable code if ...
    (comp.lang.c)
  • Re: char vs int
    ... and on a platform like a DSP where packed character handling is ... not deemed to be terribly important by the C implementor, ...
    (comp.std.c)
  • Re: char vs int
    ... and on a platform like a DSP where packed character handling is ... not deemed to be terribly important by the C implementor, ...
    (comp.std.c)
  • Re: Purchase microcontroller dev. kit
    ... A choice for a CPU should be driven by the question: ... a choice for a platform should be made with great care. ... Why do you think the OP needs a 32 bits DSP? ... suggested goes from less than 16 pins to over 256 pins. ...
    (sci.electronics.design)
  • Re: include file rule
    ... except the new-line character and " '. ... inside quotation marks in my source code in #include directives. ... But what if I give you my source to port to some platform where these ... include files and source files when you put them on your file system. ...
    (comp.lang.c.moderated)