Writing portable software

J

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.
 
I

Ian Bell

Jason said:
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
 
J

Jens.Toerring

Jason Curl said:
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>
said:
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
 
R

Richard Tobin

For example, MacOSX complained about <string.h>.
[/QUOTE]
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
 
R

Roy Hills

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
 
J

Jens.Toerring

Richard Tobin said:
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
 
R

Richard Tobin

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 said:
It would be good if the OP would cite
the full error message was, otherwise it's all guesswork.

Yes!

-- Richard
 
F

Flash Gordon

Jason said:
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.
 
W

William Ahern

Jason Curl said:
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?DOC=7990989775&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.
 
J

Jason Curl

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



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.



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.
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.
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.
 
F

Flash Gordon

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.

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.
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.
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top