Writing portable software

[Jason Curl]

Dear C group,

I'm very interested in writing portable C, but I only have GNU, Sparc
and Cygwin to compile on.

What I find is the biggest problem to writing portable C is what headers
to include. What sites do people know about that are comprehensive in
their differences?

For example, MacOSX complained about <string.h>. With Solaris I needed
to include another header file other than <fcntrl.h> to get definitions
for changing the nonblocking status of reading/writing files.

If there is a definitive guide between "modern" systems, this would be
very helpful.

TIA.
Jason.

[Ian Bell]

Jason Curl wrote:

Dear C group,

I'm very interested in writing portable C, but I only have GNU, Sparc
and Cygwin to compile on.

What I find is the biggest problem to writing portable C is what headers
to include. What sites do people know about that are comprehensive in
their differences?

For example, MacOSX complained about <string.h>. With Solaris I needed
to include another header file other than <fcntrl.h> to get definitions
for changing the nonblocking status of reading/writing files.

If there is a definitive guide between "modern" systems, this would be
very helpful.

TIA.
Jason.

The simplest answer is to adhere to some standard and perhaps the best
choice is one of the ANSI standards. With gcc you can use the
-std=standard option to define which standard to use.

IAn
--
Ian Bell

[Jens.Toerring]

Jason Curl <j_********@motorola.com> wrote:

I'm very interested in writing portable C, but I only have GNU, Sparc
and Cygwin to compile on. What I find is the biggest problem to writing portable C is what headers
to include. What sites do people know about that are comprehensive in
their differences?
The C standard(s) list all include files that you can protably use. For
C89 these are

<assert.h> <locale.h> <stddef.h>
<ctype.h> <math.h> <stdio.h>
<errno.h> <setjmp.h> <stdlib.h>
<float.h> <signal.h> <string.h>
<limits.h> <stdarg.h> <time.h>

and C99 adds the following

<complex.h> <iso646.h> <tgmath.h>
<fenv.h> <stdbool.h> <wchar.h>
<inttypes.h> <stdint.h> <wctype.h>
For example, MacOSX complained about <string.h>.
Then the compiler isn't standard compliant and you have no chance
to write anything portably.
With Solaris I needed
to include another header file other than <fcntrl.h> to get definitions
for changing the nonblocking status of reading/writing files.
Standard C doesn't allow you to set a "non-blocking" status - you
must already be using some non-standard functions (like open() or
fcntl() etc.) to be able to do that.
If there is a definitive guide between "modern" systems, this would be
very helpful.

It's not a question which system you're using but you must restrict
yourself to what the C standard specifies. If you don't mean portable
in a C sense, there are also other standards, so you can write portable
programs e.g. as far as the POSIX standard goes, but then you should
ask in e.g. comp.unix.programmer.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Roy Hills]

On Mon, 14 Mar 2005 15:30:33 +0100, Jason Curl
<j_********@motorola.com> wrote:

I'm very interested in writing portable C, but I only have GNU, Sparc
and Cygwin to compile on.

What I find is the biggest problem to writing portable C is what headers
to include. What sites do people know about that are comprehensive in
their differences?

It's a little OT, but I've found GNU Autoconf and Automake invaluable
for this sort of thing. It doesn't solve the problem, but it does
make handling the problem much easier.

You're right that finding which header files to include is one of the
big problems, but it's not the only one. You'll probably find that
some OSes don't have all the functions that you need, so you need to
write replacements (e.g. Linux has getopt_long_only, but FreeBSD
doesn't).

Roy

[Richard Tobin]

In article <39*************@uni-berlin.de>,
<Je***********@physik.fu-berlin.de> wrote:

For example, MacOSX complained about <string.h>.

Then the compiler isn't standard compliant and you have no chance
to write anything portably.

Thousands, probably millions, of programs are compiled using
<string.h> every day. The OP's real problem must be something else.

-- Richard

[Jens.Toerring]

Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <39*************@uni-berlin.de>,
<Je***********@physik.fu-berlin.de> wrote:

For example, MacOSX complained about <string.h>.

Then the compiler isn't standard compliant and you have no chance
to write anything portably.

Thousands, probably millions, of programs are compiled using
<string.h> every day. The OP's real problem must be something else.

I heard that there are some systems tha have a <strings.h> instead
of the correct <string.h> - perhaps MacOSX is one of them, I can't
tell since I never used it. It would be good if the OP would cite
the full error message was, otherwise it's all guesswork.

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Richard Tobin]

In article <39*************@uni-berlin.de>,
<Je***********@physik.fu-berlin.de> wrote:

I heard that there are some systems tha have a <strings.h> instead
of the correct <string.h> - perhaps MacOSX is one of them
No, MacOS X has a perfectly good string.h (it also has strings.h which
was the traditional BSD name, but that just #includes <string.h>).
It would be good if the OP would cite
the full error message was, otherwise it's all guesswork.

Yes!

-- Richard

[Flash Gordon]

Jason Curl wrote:

Dear C group,

I'm very interested in writing portable C, but I only have GNU, Sparc
and Cygwin to compile on.
Good, because portable C is what we specialise in here.
What I find is the biggest problem to writing portable C is what headers
to include. What sites do people know about that are comprehensive in
their differences?
It depends on how portable you want to be. Portability here generally
means sticking to ISO standard C and, due to the lack of C99 compilers,
sticking to the old C90 standard. I would suggest the FAQ for
comp.lang.c and buying a copy of K&R2 would be a good start. Note that
ONE chapter of K&R2 is not portable because it is talking about Unix,
but the rest is portable.

If you want to go beyond what ISO C requires, then you need to decide
what systems you want to be portable to and whether they follow any
common standard such as POSIX, but any such standard are off topic here.
For example, MacOSX complained about <string.h>.
It should not complain about string.h since that is an ISO standard
header. Query that on a MacOSX group.
With Solaris I needed
to include another header file other than <fcntrl.h> to get definitions
for changing the nonblocking status of reading/writing files.
That is beyond what ISO C provides, so you will have to decide what
systems you want to be portable to and see if there is a common standard.
If there is a definitive guide between "modern" systems, this would be
very helpful.

There is probably no definitive guide for things outside ISO C that I am
aware of since Windows and *nix are rather different. However, there are
libraries ported to a number of systems that can help with portability.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[William Ahern]

Jason Curl <j_********@motorola.com> wrote:

Dear C group, I'm very interested in writing portable C, but I only have GNU, Sparc
and Cygwin to compile on. What I find is the biggest problem to writing portable C is what headers
to include. What sites do people know about that are comprehensive in
their differences?
http://oakroadsystems.com/tech/c-predef.htm
For example, MacOSX complained about <string.h>. With Solaris I needed
to include another header file other than <fcntrl.h> to get definitions
for changing the nonblocking status of reading/writing files.
These are Unix'ish systems. Interfaces exposing things like "changing the
nonblock status of reading/writing files" is not portable C, though is
generally portable among Unix systems (and most definitely not portable
between Unix and Windows). Most Unices generally expose their common
interfaces according to the Standard Unix Specification.

http://www.opengroup.org/onlinepubs/009695399/toc.htm.

You're supposed to first fill out this harmless form before viewing the
specification.

http://www.opengroup.org/online-pubs...9775&FORM=HTML
If there is a definitive guide between "modern" systems, this would be
very helpful.

None other than the C standards. For the "fun" stuff you have to become
platform specific, and the Unix platform is about as general as you can get
without being forced to delve into platform specific stuff. (I suppose that
follows from my definition of general.)

A good Unix group is comp.unix.programmer.

[Jason Curl]

Flash Gordon wrote:

Jason Curl wrote:

Dear C group,

I'm very interested in writing portable C, but I only have GNU, Sparc
and Cygwin to compile on.

Good, because portable C is what we specialise in here.

What I find is the biggest problem to writing portable C is what
headers to include. What sites do people know about that are
comprehensive in their differences?

It depends on how portable you want to be. Portability here generally
means sticking to ISO standard C and, due to the lack of C99 compilers,
sticking to the old C90 standard. I would suggest the FAQ for
comp.lang.c and buying a copy of K&R2 would be a good start. Note that
ONE chapter of K&R2 is not portable because it is talking about Unix,
but the rest is portable.

I've read K&R 2 a long time ago and staying to the C90 standard I agree
is the best.

If you want to go beyond what ISO C requires, then you need to decide
what systems you want to be portable to and whether they follow any
common standard such as POSIX, but any such standard are off topic here.

For example, MacOSX complained about <string.h>.

It should not complain about string.h since that is an ISO standard
header. Query that on a MacOSX group.

Sorry - I don't have MacOSX, a friend of mine has and he compiled
something for me. The solution to the problem was including another
header file, don't remember exactly what - strings.h or string.h.

> With Solaris I needed

to include another header file other than <fcntrl.h> to get
definitions for changing the nonblocking status of reading/writing files.

That is beyond what ISO C provides, so you will have to decide what
systems you want to be portable to and see if there is a common standard.

Any suggestions of other newsgroups I could ask? I guess specific
newsgroups would only give me information specific to a compiler or
platform, but what is really needed is some kind of comparison list.
I've seen that GNU AutoConf tools documentation contains a small list.

If there is a definitive guide between "modern" systems, this would be
very helpful.

There is probably no definitive guide for things outside ISO C that I am
aware of since Windows and *nix are rather different. However, there are
libraries ported to a number of systems that can help with portability.

Narrowing down the search, if we remove "Windows" and go for POSIX-like
systems (e.g. QNX, BSD, GNU, Cygwin, MacOSX).

But most of all, thanks for the help so far.

[Flash Gordon]

Jason Curl wrote:

Flash Gordon wrote:

Jason Curl wrote:

Dear C group,

I'm very interested in writing portable C, but I only have GNU, Sparc
and Cygwin to compile on.
<snip>

I've read K&R 2 a long time ago and staying to the C90 standard I agree
is the best.
Well, you should keep a copy handy as a reference. Mine is sat on my
desk at work.

<snip>
For example, MacOSX complained about <string.h>.

It should not complain about string.h since that is an ISO standard
header. Query that on a MacOSX group.

Sorry - I don't have MacOSX, a friend of mine has and he compiled
something for me. The solution to the problem was including another
header file, don't remember exactly what - strings.h or string.h.

Well, either you were using a non-standard function or your friends
install was broken.

With Solaris I needed
to include another header file other than <fcntrl.h> to get
definitions for changing the nonblocking status of reading/writing
files.

That is beyond what ISO C provides, so you will have to decide what
systems you want to be portable to and see if there is a common standard.

Any suggestions of other newsgroups I could ask? I guess specific
newsgroups would only give me information specific to a compiler or
platform, but what is really needed is some kind of comparison list.
I've seen that GNU AutoConf tools documentation contains a small list.

I would suggest that comp.programming would be a good start.

If there is a definitive guide between "modern" systems, this would
be very helpful.

There is probably no definitive guide for things outside ISO C that I
am aware of since Windows and *nix are rather different. However,
there are libraries ported to a number of systems that can help with
portability.

Narrowing down the search, if we remove "Windows" and go for POSIX-like
systems (e.g. QNX, BSD, GNU, Cygwin, MacOSX).

If you stick to POSIX like systems, comp.unix.programmer would be a good
place to start.

You *may* find that Windows groups can help with the differences between
Windows and POSIX, failing that comp.programming. It *is* possible to
write SW that goes beyond the C standard that runs on Windows and *nix,
but depending on what you want to do it can take a bit of work.
But most of all, thanks for the help so far.

OK, but now you have a better group to ask in for the bits beyond the C
standard.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.