C Program Portability

[Andrew Au \(Newsgroup\)]

Anyone can list the difference between Solaris SunOS/Cygwin/Redhat?

I know SunOS has a byte ordering problem.

What else? Are there any website to list these difference?
What are the constructs to be avoided to write portable C program?


It maybe OT, coz' it is about system specific details, but because it is
multiple platform, and it is about C, I think the closest newsgroup is
c.l.c.
Maybe this group should discuss issue of wider range, only C standard, or
standard C, is too narrow of any discussion, almost all useful discussion in
C is OT. If it is simply about standard, why not just refer people to the
webpage listing C standard and close this group?

 

[Artie Gold]

Anyone can list the difference between Solaris SunOS/Cygwin/Redhat?

I know SunOS has a byte ordering problem.

What else? Are there any website to list these difference?
What are the constructs to be avoided to write portable C program?

If you write portable code, no problem.

It maybe OT, coz' it is about system specific details, but because it is

It is.

multiple platform, and it is about C, I think the closest newsgroup is
c.l.c.

If you write portable code, no problem.

Maybe this group should discuss issue of wider range, only C standard, or
standard C, is too narrow of any discussion, almost all useful discussion in
C is OT. If it is simply about standard, why not just refer people to the
webpage listing C standard and close this group?

It is not about the standard, it is about the ISO standard C language --
a pretty rich topic in and of itself.

There are system specific newsgroups for system specific issues.

--ag

[BTW -- see Sun's website for Solaris/Linux issues]

 

[Arthur J. O'Dwyer]

Anyone can list the difference between Solaris SunOS/Cygwin/Redhat?

Operating system, for one thing.

I know SunOS has a byte ordering problem.

ITYM /Intel/ has a byte ordering problem.

What else? Are there any website to list these difference?
What are the constructs to be avoided to write portable C program?

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;
buf[2] = i>>16;
buf[3] = i>>24;
fwrite(buf, 1, sizeof buf, fp); /* good! */

int i = 65536; /* bad! */
long i = 65536; /* good! */

FILE *fp = fopen("foo", "rb");
if (getc(fp) == '\n') /* bad! */
if (getc(fp) == 0x0A) /* good! */

FILE *fp = fopen("foo", "r");
if (getc(fp) == '\n') /* good! */

return add(get_term(), get_term()); /* bad! */

term t = get_term();
return add(t, get_term()); /* good! */

It maybe OT, coz' it is about system specific details, but because it is
multiple platform, and it is about C, I think the closest newsgroup is
c.l.c.

Yes, probably. But if you want real answers, you're going to have to
ask real questions. The generic "I'm a newbie. What do I do?" kind of
question doesn't usually get good answers here (and my response is no
exception). You might try comp.programming for your broader portability
concerns (as in, "what weird things will I encounter in the field?"),
and/or alt.comp.lang.learn.c-c++ for your pedagogically-oriented answers.
For starters, read the FAQs of both clc and acllcc++. They will help
you immensely.

Maybe this group should discuss issue of wider range, only C standard, or
standard C, is too narrow of any discussion, almost all useful discussion in
C is OT. If it is simply about standard, why not just refer people to the
webpage listing C standard and close this group?

Because the Standard is so highly arcane (in some sections) that there's
a whole group (comp.std.c) devoted simply to interpreting and revising
the Standard document! This group is not about the Standard document.
It's about using the real-world language defined by the Standard. And
that's plenty for one group; we don't need to try to cope with all your
Unix and MFC and OpenGL and Java questions into the bargain!

More succinctly: Because the Standard isn't available on any
publicly-accessible webpage. The nearest thing is N869 (Google it);
the Standard itself costs $18 from ANSI and other national bodies.

HTH,
-Arthur

 

[Flash Gordon]

Anyone can list the difference between Solaris SunOS/Cygwin/Redhat?

Operating system, for one thing.

I know SunOS has a byte ordering problem.

ITYM /Intel/ has a byte ordering problem.

What else? Are there any website to list these difference?
What are the constructs to be avoided to write portable C program?

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 ?

buf[2] = i>>16;

Very bad, what if sizeof int <= 2 ?

buf[3] = i>>24;
fwrite(buf, 1, sizeof buf, fp); /* good! */

<snip>

OK, so on most hosted systems that the OP is likely to use CHAR_BIT==8
(I know some real systems have other values, but those are rather less
common) but for portable binary formats you do have to be very careful
and allow for what mechanism will be used for transferring the data and
if CHAR_BIT>8 how this will affect the layout of the bits in a shared
resource such as a binary file. Text formats are generally easier to
deal with, although you still have to transfer them in a way that
ensures that they are converted to the native text format.

 

[SM Ryan]

# Anyone can list the difference between Solaris SunOS/Cygwin/Redhat?
#
# I know SunOS has a byte ordering problem.

It's not a problem, it's a feature.

Byte order issues occur when you view a multibyte value, like a binary int, as both
the multibyte value and as a byte string. Most I/O mediums convert to a byte string
and then back to an internal value, so this also shows up if you write a binary value
on one machine and read it back on another.

# What else? Are there any website to list these difference?
# What are the constructs to be avoided to write portable C program?

See if they all claim to obey a particular standard like ANSI C or Posix or SVID
or CIE LAB. If so, you can code to that standard.

 

[Arthur J. O'Dwyer]

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.

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.

-Arthur

 

[Flash Gordon]

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.