code portability

[Eigenvector]

My question is more generic, but it involves what I consider ANSI standard C
and portability.

I happen to be a system admin for multiple platforms and as such a lot of
the applications that my users request are a part of the OpenSource
community. Many if not most of those applications strongly require the
presence of the GNU compiling suite to work properly. My assumption is that
this is due to the author/s creating the applications with the GNU suite.
Many of the tools requested/required are GNU replacements for make,
configure, the loader, and lastly the C compiler itself. Where I'm going
with this is, has the OpenSource community as a whole committed itself to at
the very least encouraging its contributing members to conform to ANSI
standards of programming?

My concern is that as an admin I am sometimes compelled to port these
applications to multiple platforms running the same OS and as the user
community becomes more and more insistent on OpenSource applications will
gotcha's appear due to lack of portability in coding? I fully realize that
independent developers may or may not conform to standards, but again is it
at least encouraged?

11.32 of the FAQ seemed to at least outline the crux of what I am asking.
If I loaded up my home machine to the gills will all open source compiler
applications (gcc, imake, autoconfig, etc....) would my applications that I
compile and link and load conform?

 

[Tom St Denis]

My question is more generic, but it involves what I consider ANSI standard C
and portability.

I happen to be a system admin for multiple platforms and as such a lot of
the applications that my users request are a part of the OpenSource
community. Many if not most of those applications strongly require the
presence of the GNU compiling suite to work properly. My assumption is that
this is due to the author/s creating the applications with the GNU suite.
Many of the tools requested/required are GNU replacements for make,
configure, the loader, and lastly the C compiler itself. Where I'm going
with this is, has the OpenSource community as a whole committed itself to at
the very least encouraging its contributing members to conform to ANSI
standards of programming?

GCC attempts to conform to C90 and C99 and in many regards it's there.
If you disable GNU extensions [or just plain don't use them, cuz if
you're not writing a kernel you probably don't need them] you're pretty
much set.

My concern is that as an admin I am sometimes compelled to port these
applications to multiple platforms running the same OS and as the user
community becomes more and more insistent on OpenSource applications will
gotcha's appear due to lack of portability in coding? I fully realize that
independent developers may or may not conform to standards, but again is it
at least encouraged?

The C library [glibc] and other libs [pthreads, sockets, etc] follow
various UNIX, POSIX and ANSI standards. There are minor gotchas (for
instance, pthreads is part of the glibc in Linux but not in other
UNIXes) but for the most part source compatibility is there.

11.32 of the FAQ seemed to at least outline the crux of what I am asking.
If I loaded up my home machine to the gills will all open source compiler
applications (gcc, imake, autoconfig, etc....) would my applications that I
compile and link and load conform?

Read the man pages. Make sure the functions you use conform to some
standard and are not specific to your OS (e.g. not Linux only).

You'd be surprised how much of the standard libraries are API
consistent across UNIX, BSD and Linux.

Tom

 

[Eigenvector]

My question is more generic, but it involves what I consider ANSI
standard C
and portability.

I happen to be a system admin for multiple platforms and as such a lot of
the applications that my users request are a part of the OpenSource
community. Many if not most of those applications strongly require the
presence of the GNU compiling suite to work properly. My assumption is
that
this is due to the author/s creating the applications with the GNU suite.
Many of the tools requested/required are GNU replacements for make,
configure, the loader, and lastly the C compiler itself. Where I'm going
with this is, has the OpenSource community as a whole committed itself to
at
the very least encouraging its contributing members to conform to ANSI
standards of programming?

GCC attempts to conform to C90 and C99 and in many regards it's there.
If you disable GNU extensions [or just plain don't use them, cuz if
you're not writing a kernel you probably don't need them] you're pretty
much set.

What about the programmers who submit to the archives? That is mainly where
I see massive gcc and imake requirements. In fact I have on occassion
attempted to compile applications - such as gcc using my native Intel or xlC
compilers without luck. Again this isn't a question on how to compile GCC,
but rather is the experience that the OpenSource community tries to conform
to ANSI standards?

My concern is that as an admin I am sometimes compelled to port these
applications to multiple platforms running the same OS and as the user
community becomes more and more insistent on OpenSource applications will
gotcha's appear due to lack of portability in coding? I fully realize
that
independent developers may or may not conform to standards, but again is
it
at least encouraged?

The C library [glibc] and other libs [pthreads, sockets, etc] follow
various UNIX, POSIX and ANSI standards. There are minor gotchas (for
instance, pthreads is part of the glibc in Linux but not in other
UNIXes) but for the most part source compatibility is there.

11.32 of the FAQ seemed to at least outline the crux of what I am asking.
If I loaded up my home machine to the gills will all open source compiler
applications (gcc, imake, autoconfig, etc....) would my applications that
I
compile and link and load conform?

Read the man pages. Make sure the functions you use conform to some
standard and are not specific to your OS (e.g. not Linux only).

You'd be surprised how much of the standard libraries are API
consistent across UNIX, BSD and Linux.

Tom

 

[Richard Heathfield]

Eigenvector said:

Where I'm going
with this is, has the OpenSource community as a whole committed itself to
at the very least encouraging its contributing members to conform to ANSI
standards of programming?

I doubt it very much, unfortunately.

My concern is that as an admin I am sometimes compelled to port these
applications to multiple platforms running the same OS and as the user
community becomes more and more insistent on OpenSource applications will
gotcha's appear due to lack of portability in coding?

It's entirely possible that they will. Unfortunately, open source code is
not, generally speaking, known for its robustness or portability. In fact,
I can think of only one kind of source base that is less robust and less
portable than open source code - and that's closed source code.

I fully realize
that independent developers may or may not conform to standards, but again
is it at least encouraged?

We do our bit, here in comp.lang.c, but I doubt whether it's enough to make
more than a small difference.

 

[Tom St Denis]

What about the programmers who submit to the archives? That is mainly where
I see massive gcc and imake requirements. In fact I have on occassion
attempted to compile applications - such as gcc using my native Intel or xlC
compilers without luck. Again this isn't a question on how to compile GCC,
but rather is the experience that the OpenSource community tries to conform
to ANSI standards?

GCC is hardly your average OSS project (and Intel C is hardly standard
conforming).

Generally if you don't use any special features of GNU make you should
be "make portable". My makefiles are used in windows, linux, bsd, AIX,
HP-UX, MacOS, etc, etc, etc even though they split between proprietary
make, imake, gmake, etc, etc, etc.

Aim for C89 compliance and you pretty much got things nailed. Keep in
mind that many compilers supported various C99 features even back then.
E.g., long long has been supported for a while and ALL unix C
compilers I've seen support it [even the ones released in the mid 90s].

Avoid VLAs, // comments and the newer header files if you want the
widest possible reach.
Tom

 

[jacob navia]

Avoid VLAs, // comments and the newer header files if you want the
widest possible reach.
Tom

You should also avoid long long. This did not exist in C89.

To add 64 bit quantities you should develop and use
add64bits(a,b);
sub64bits(a,b);
mult64bits(a,b);

etc ad nauseum.

You should also avoid long double. This did not exist in C89.

To add two long doubles you should develop and use a package
with extended floating point precision.

addlongdouble(a,b);
sublongdouble(a,b);

ad nauseum.


You should not have any array that goes beyond 32K. The size
of an integer should not be bigger than 16 bits, because that
is the minimum required by C89 if I remember correctly.

This is very easy to do: make a linked list of 32K chunks and you can
have (GASP!) arrays of maybe a MB... You should not write
int array[65000];

int m = array[45765];

but
ArrayList *newintArrayList(65000);
m = getintItem(array,45765U);

For doubles you write

ArrayList *newdoubleArrayList(65000);
m = getdoubleItem(array,45765U);

If you want indexes bigger than 65535 you should develop a 32 bit
integer package.

And after you have developed all that you can (GASP!!!) develop your
application if you have any time left.


Obviously you should buy the new Intel biprocessor or the AMD Quad
processor to handle all that overhead but who cares? Your program
will be portable to the embedded processor in the WC...

 

[Richard Bos]

You should also avoid long double. This did not exist in C89.

Oh, look, isn't it just *darling*? I'd ask if we could keep it, but
frankly I'd prefer if it kept it and its rampant lack of knowledge about
C to itself.

Richard

 

[jacob navia]

Oh, look, isn't it just *darling*? I'd ask if we could keep it, but
frankly I'd prefer if it kept it and its rampant lack of knowledge about
C to itself.

Richard

Nothing to the other points *darling* ?

 

[Tom St Denis]

You should also avoid long long. This did not exist in C89.

Except it is valid "C" and many [most] C compilers do in fact support
it. In fact the only compiler I know of in productive use on 32/64 bit
boxes that doesn't is MSVC and there is a simple workaround (it has a
64-bit type just not called long long0.

So your "advice" is ignorant ranting lunatic bullshit.

To add 64 bit quantities you should develop and use
add64bits(a,b);
sub64bits(a,b);
mult64bits(a,b);

Or ... not use crappy toy compilers.

All UNIX CC's I've seen support it. GCC supports it [since well before
C99], MSVC even supports it (indirectly).

Your comment is not well founded.

You should also avoid long double. This did not exist in C89.

You should avoid floats entirely if you want portable code. Many
modern platforms don't have FPUs at all.

So unless your code really needs it you shouldn't use them.

You should not have any array that goes beyond 32K. The size
of an integer should not be bigger than 16 bits, because that
is the minimum required by C89 if I remember correctly.

12345676UL

That's valid C89. Shut the **** up.

Array indecies only have to be of integer type. Chances are, if your
platform only supports 32K or 64K arrays you don't have that much
memory to work with anyways. So it's moot.

No amount of unportable coding will give you 1MB of ram on an 8051
(typically 8051s don't use much if any bank switching in the field....)

And after you have developed all that you can (GASP!!!) develop your
application if you have any time left.

Bullshit. It's totally valid to do

char *p = malloc(100000L * sizeof(*p));

then do p[45000] = 3;

If and only if p != NULL.

A platform may not support such requests (e.g. if segments were 32KB
for instance) and reject the malloc request. It's true that the
compiler doesn't have to support large objects, but that's an OPTIONAL
limitation only imposed when the PHYSICAL limitations of the platform
makes it troublesome to work around it.

Obviously you should buy the new Intel biprocessor or the AMD Quad
processor to handle all that overhead but who cares? Your program
will be portable to the embedded processor in the WC...

For someone who develops for windows you seem to have an odd view of
"overhead" and waste....

Tom

 

[jacob navia]

You should also avoid long long. This did not exist in C89.

Except it is valid "C" and many [most] C compilers do in fact support
it. In fact the only compiler I know of in productive use on 32/64 bit
boxes that doesn't is MSVC and there is a simple workaround (it has a
64-bit type just not called long long0.

See?

Not portable then.

So your "advice" is ignorant ranting lunatic bullshit.

WOW what nice arguments

Or ... not use crappy toy compilers.

Exactly. Use C99.

All UNIX CC's I've seen support it. GCC supports it [since well before
C99], MSVC even supports it (indirectly).

Your comment is not well founded.

You should also avoid long double. This did not exist in C89.

You should avoid floats entirely if you want portable code. Many
modern platforms don't have FPUs at all.

So unless your code really needs it you shouldn't use them.

You should not have any array that goes beyond 32K. The size
of an integer should not be bigger than 16 bits, because that
is the minimum required by C89 if I remember correctly.

12345676UL

That's valid C89. Shut the **** up.

This is not portable to 16 bit machines. Per standard (C99) the minimum
integer size is 16 bit only. I would be surprised that C89 was
different.

Array indecies only have to be of integer type.

Yes, and the minimum required int size is 16 bits.

 

[jacob navia]

Oh, look, isn't it just *darling*? I'd ask if we could keep it, but
frankly I'd prefer if it kept it and its rampant lack of knowledge about
C to itself.

Richard

I stand corrected. Apparently C89 did have long double.

 

[Tom St Denis]

Except it is valid "C" and many [most] C compilers do in fact support
it. In fact the only compiler I know of in productive use on 32/64 bit
boxes that doesn't is MSVC and there is a simple workaround (it has a
64-bit type just not called long long0.

See?

Not portable then.

Um, ok but it's trivial to work around. you can still use

ulong64 a, b, c;

a += b;
c *= b;
b ^= a;

After you find a typedef for ulong64. On real compilers it's "unsigned
long long" and on msvc it's "unsigned __int64" [irrc].

That's a stupidly quick fix. I support it in LibTomCrypt since day-1
and haven't looked back since.

WOW what nice arguments

Well given my software is used on pretty much every 32 and 64-bit C
platform you can think of I'd say I'm abundantly qualified to talk
about getting code to work portably.

Your rants [which I think are just a joe-job against the real Jacob]
are pure troll ignorant trash.

Exactly. Use C99.

Um, no read what I'm actually writing. Real compilers supported it
before C99.

This is not portable to 16 bit machines. Per standard (C99) the minimum
integer size is 16 bit only. I would be surprised that C89 was
different.

um,

unsigned long = 1234567UL;

That's valid C89 code. Any compiler that doesn't support that is not a
C89 compiler and is not worth discussing [hint: BYTE Small-C from 1985
is not a C89 compiler!]

Yes, and the minimum required int size is 16 bits.

Yes, so if your malloc of 100000 bytes fails you can exit gracefully.
I agree that static or globals of huge size are a bad idea (in general
they're a bad idea anyways).

That said, you generally don't assume that a program that uses huge
arrays will port directly to a 8-bit host anyways?

By your logic, C is a bad language because Apache2 won't build on my
8051.

"Portable" code has limits. But between tiny alarm clock programs and
vast server applications is an entire spectrum of applications that
work in a variety of environments. For instance, Info-Zip was being
used in 16, 32 and 64 bit platforms (of various endianesses) at the
same time.

Your rants are ignorant and shameful. My guess is you haven't spent 5
minutes trying to write portable code and you're just upset that you
think you're moot since you've missed the boat.

How about you be a team player for a change?

Tom

 

[Al Balmer]

Where I'm going
with this is, has the OpenSource community as a whole committed itself to at
the very least encouraging its contributing members to conform to ANSI
standards of programming?

No, because there's no such entity as "the OpenSource community as a
whole." Individual projects may have guidelines.

 

[Kenneth Brody]

Tom St Denis wrote:
[...]

Aim for C89 compliance and you pretty much got things nailed. Keep in
mind that many compilers supported various C99 features even back then.
E.g., long long has been supported for a while and ALL unix C
compilers I've seen support it [even the ones released in the mid 90s].

[...]

SCO OpenServer 5 doesn't have "long long" support, and the compiler
says it's dated "18Feb03".

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Tom St Denis]

Tom St Denis wrote:
[...]

Aim for C89 compliance and you pretty much got things nailed. Keep in
mind that many compilers supported various C99 features even back then.
E.g., long long has been supported for a while and ALL unix C
compilers I've seen support it [even the ones released in the mid 90s].

[...]

SCO OpenServer 5 doesn't have "long long" support, and the compiler
says it's dated "18Feb03".

Who the **** uses SCO? When I say UNIX I mean IRIX, Solaris, HP-UX,
AIX, etc...

SCO is the OS of choice for the anti-christ.

Tom

 

[Walter Roberson]

Who the **** uses SCO? When I say UNIX I mean IRIX, Solaris, HP-UX,
AIX, etc...

The OpenGroup certified UNIXes are [specific versions of]

AIX (IBM)
IRIX (SGI)
NCR UNIX (NCR)
Solaris (Sun, Fujitsu)
Tru64 (HP)
UnixWare (Caldera, SCO)
UX/4800 (NEC)


Regardless of what one thinks of SCO, they -are- one of the few
certified UNIX.

 

[Martin Ambuhl]

You should also avoid long double. This did not exist in C89.

Jacob Navia once again proves he knows nothing. From the C89 ANSI
standard, even before the ISO C90 standard:

3.1.2.5 Types
[...]
There are three floating types, designated as float , double , and
long double . The set of values of the type float is a subset of the
set of values of the type double ; the set of values of the type
double is a subset of the set of values of the type long double.

When Jacob is not pretending that his compiler's non-standard features
define the world, he pretends that C does not include what it has
included for 17 years. Is he ignorant or dishonest?

 

[Richard Heathfield]

Martin Ambuhl said:

When Jacob is not pretending that his compiler's non-standard features
define the world, he pretends that C does not include what it has
included for 17 years. Is he ignorant or dishonest?

Hanlon's Razor applies.

 

[Flash Gordon]

Who the **** uses SCO? When I say UNIX I mean IRIX, Solaris, HP-UX,
AIX, etc...

The OpenGroup certified UNIXes are [specific versions of]

AIX (IBM)
IRIX (SGI)
NCR UNIX (NCR)
Solaris (Sun, Fujitsu)
Tru64 (HP)
UnixWare (Caldera, SCO)
UX/4800 (NEC)


Regardless of what one thinks of SCO, they -are- one of the few
certified UNIX.

Also it *is* still used. I even have a SCO box in the office for doing
critical fixes to an old version of our software. Fortunately I've
persuaded the company not to support SCO for the current version.

 

[Clever Monkey]

Who the **** uses SCO? When I say UNIX I mean IRIX, Solaris, HP-UX,
AIX, etc...

The OpenGroup certified UNIXes are [specific versions of]

AIX (IBM)
IRIX (SGI)
NCR UNIX (NCR)
Solaris (Sun, Fujitsu)
Tru64 (HP)
UnixWare (Caldera, SCO)
UX/4800 (NEC)

Regardless of what one thinks of SCO, they -are- one of the few
certified UNIX.

Also it *is* still used. I even have a SCO box in the office for doing
critical fixes to an old version of our software. Fortunately I've
persuaded the company not to support SCO for the current version.

[So off-topic that I set follow-ups.]

You too, huh? I actually had to rescue my OpenServer CDs from the
"coaster heap" in order to pull together a system as a good-faith move
for a customer.

It's true: people still use this stuff.