Re: C Program Portability
From: Flash Gordon (spam_at_flash-gordon.me.uk)
Date: 09/23/04
- Next message: Flash Gordon: "Re: newbie-question: comments"
- Previous message: CBFalconer: "Re: Newbie-question: scanf alternatives?"
- In reply to: Arthur J. O'Dwyer: "Re: C Program Portability"
- Next in thread: SM Ryan: "Re: C Program Portability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 23 Sep 2004 22:18:34 +0100
On Thu, 23 Sep 2004 00:39:48 -0400 (EDT)
"Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote:
> On Wed, 22 Sep 2004, Flash Gordon wrote:
> >
> > "Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote:
> >>
> >> Avoid non-portable constructs. That is, avoid those constructs
> >> with implementation-defined, unspecified, or undefined behavior.
> >> Some examples include
> >>
> >> int i;
> >> fwrite(&i, sizeof i, 1, fp); /* bad! */
> >>
> >> unsigned char buf[sizeof (int)];
> >> buf[0] = i>>0;
> >> buf[1] = i>>8;
> >
> > Bad. What if CHAR_BIT!=8 ?
>
> Then we waste a few bits. I have absolutely no experience with
> porting data files between systems with different byte widths, but I
> imagine it might be easier and more useful to convert 9-bit bytes to
> 8-bit bytes by truncation, than to copy the exact bit pattern. In
> other words, in cases where it matters, this is a feature, not a bug.
I was thinking more of a 16 bit byte. Imagine this, you write your file
out on the 16 bit byte machine then transfer it to an 8 bit byte
machine. Now, since this is a binary file, any transfer is likely to
convert every 16 bit byte in to *two* 8 bit bytes, since to do otherwise
looses information. Then you have problems reading it!
Hence the comment I should have made (but may have forgotten to make)
that any code writing data as a binary file needs to be adapted for the
range of systems being used, and that the simplest way of dealing with
some possible systems is with different versions of the code.
> >> buf[2] = i>>16;
> >
> > Very bad, what if sizeof int <= 2 ?
>
> Hmm, yes, that is UB, isn't it? Better make that something like
>
> if (INT_MAX > 32767) {
> buf[2] = i >> 16;
> if ( [...???...] )
> buf[3] = i >> 24;
> else buf[3] = 0;
> }
> else buf[2] = buf[3] = 0;
>
> ...except that I can't think what to put in the [...???...] condition
> that would be strictly portable. Comparison to 8388607 isn't right.
>
> Of course, if I had taken my own advice and used 'long int' instead
> of 'int' in the first place (and 'unsigned long int' for any values
> that would need writing out to a file), then we wouldn't be having
> this conversation. :)
It's more that if you are dealing with reading, processing, writing a
binary format (say, doing some image processing on a greyscale image
with 16 bits per pixel, you might want to use different types on
different systems. If dealing with something less bulky, for instance
exporting a balanced ledger (financial data) from one system and
importing it to another (something I am involved in) you will probably
want to use a text format, since that can easily be produced and
easily be interpreted and translations between text formats can
generally be handled by the tool (FTP, for instance, which definitely
does line termination translation when told to transfer in text mode)
used to transfer the file.
-- Flash Gordon Sometimes I think shooting would be far too good for some people. Although my email address says spam, it is real and I read it.
- Next message: Flash Gordon: "Re: newbie-question: comments"
- Previous message: CBFalconer: "Re: Newbie-question: scanf alternatives?"
- In reply to: Arthur J. O'Dwyer: "Re: C Program Portability"
- Next in thread: SM Ryan: "Re: C Program Portability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
