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?

[Keith Thompson]

Richard Heathfield <in*****@invali d.invalidwrites :

Keith Thompson said:

>Richard Heathfield <in*****@invali d.invalidwrites :

<snip>

>>

>>The introduction of long long int was, in my continued opinion, a
mistake. All the ISO guys had to do was - nothing at all! Any
implementatio n that wanted to support 64-bit integers could simply have
made long int rather longer than before - such a system would have
continued to be fully conforming to C90. And if it broke code, well, so
what? Any code that wrongly assumes long int is precisely 32 bits is
already broken, and needs fixing.

That's true, but 64 bits is the effective limit for this.

Nope.

>The following:
char 8 bits
short 16 bits
int 32 bits
long 64 bits
is a reasonable set of types,

Indeed. So is this:

char 8 bits
short 64 bits
int 64 bits
long 64 bits

and at least one implementation does it like that.

>but if you go beyond that to 128 bits,
you're going to have to leave gaps (for example, there might not be
any 16-bit integer type).

Er, and?

Er, and I've worked on such a system, and it caused some real
problems. There was a 16-bit or 32-bit field in an externally imposed
data format. The relevant system header declared it as a bit field.
Code that assumed you could take the address of that field broke.

The C compiler could have created 16-bit and 32-bit integer types,
using the same convoluted mechanism it used to handle 8-bit types --
but if these types had been called "short" and "int", then a lot of
code would have used them and become unreasonably slow as a result.

In C99, I suppose the system could have defined them as extended
integer types, guaranteeing that they wouldn't be used unless you
explicitly asked for them. Then intfast32_t would be 64 bits, but
int32_t would be 32 bits (and slow).

That's a problem with the design of <stdint.h>; the naming scheme
assumes that exact-width types are more important than types with *at
least* a specified size or range.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <in*****@invali d.invalidwrites :

>>

>>but if you go beyond that to 128 bits,
you're going to have to leave gaps (for example, there might not be
any 16-bit integer type).

Er, and?

Er, and I've worked on such a system, and it caused some real
problems. There was a 16-bit or 32-bit field in an externally imposed
data format. The relevant system header declared it as a bit field.
Code that assumed you could take the address of that field broke.

Bit-fields are broken anyway. I'd read it a byte at a time, and copy the
bits over "by hand", so to speak.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

Richard Heathfield <in*****@invali d.invalidwrites :

Keith Thompson said:

>Richard Heathfield <in*****@invali d.invalidwrites :

>>>but if you go beyond that to 128 bits,
you're going to have to leave gaps (for example, there might not be
any 16-bit integer type).

Er, and?

Er, and I've worked on such a system, and it caused some real
problems. There was a 16-bit or 32-bit field in an externally imposed
data format. The relevant system header declared it as a bit field.
Code that assumed you could take the address of that field broke.

Bit-fields are broken anyway. I'd read it a byte at a time, and copy the
bits over "by hand", so to speak.

Yes, that's another (equally inconvenient) approach. But in any case
I didn't have the option of modifying the system header files.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Andrew Poelstra]

On 2006-08-03, Keith Thompson <ks***@mib.orgw rote:

Richard Heathfield <in*****@invali d.invalidwrites :

>The introduction of long long int was, in my continued opinion, a mistake.
All the ISO guys had to do was - nothing at all! Any implementation that
wanted to support 64-bit integers could simply have made long int rather
longer than before - such a system would have continued to be fully
conforming to C90. And if it broke code, well, so what? Any code that
wrongly assumes long int is precisely 32 bits is already broken, and needs
fixing.

That's true, but 64 bits is the effective limit for this. The
following:
char 8 bits
short 16 bits
int 32 bits
long 64 bits
is a reasonable set of types, but if you go beyond that to 128 bits,
you're going to have to leave gaps (for example, there might not be
any 16-bit integer type).

1) This isn't really a problem; you can use a 32-bit variable to store
16-bit values; if you really need 16 bits you might need some debug
macros to artificially constrain the range.
2) If you've got a 128-bit processor, IMHO, you shouldn't be insisting
on using 8-bit types. That just sounds inefficient. [OT]

--
Andrew Poelstra <http://www.wpsoftware. net/projects>
To reach me by email, use `apoelstra' at the above domain.
"Do BOTH ends of the cable need to be plugged in?" -Anon.

[lawrence.jones]

Richard Heathfield <in*****@invali d.invalidwrote:

>
The introduction of long long int was, in my continued opinion, a mistake.
All the ISO guys had to do was - nothing at all! Any implementation that
wanted to support 64-bit integers could simply have made long int rather
longer than before - such a system would have continued to be fully
conforming to C90. And if it broke code, well, so what? Any code that
wrongly assumes long int is precisely 32 bits is already broken, and needs
fixing.

The problem was not breaking code but breaking binary compatibility.
Lots of vendors wanted to add 64 bit support to their existing 32 bit
platforms (for large file support, if nothing else), but they couldn't
very well change the size of long on the existing platforms without
breaking *everything*. The expedient, if not elegant, solution was long
long. Most of the committee didn't really like the idea, but it was
already a common extension and promised to become more so, so we figured
we'd better standardize it (particularly the promotion rules) so that
people had a chance of using it portably.

-Larry Jones

Fortunately, that was our plan from the start. -- Calvin

[lawrence.jones]

Keith Thompson <ks***@mib.orgw rote:

>
My objection to C's integer type system is that the names are
arbitrary: "char", "short", "int", "long", "long long", "ginormous
long". I'd like to see a system where the type names follow a regular
pattern, and if you want to have a dozen distinct types the names are
clear and obvious.

Well, one wag did propose adding the "very" keyword to C so that,
instead of long long we could have very long (and very very long, and
very very very long, etc.), not to mention very short (and very very
short, etc.). You could even have very const....

-Larry Jones

I hope Mom and Dad didn't rent out my room. -- Calvin

[Ian Collins]

Keith Thompson wrote:

>
My objection to C's integer type system is that the names are
arbitrary: "char", "short", "int", "long", "long long", "ginormous
long". I'd like to see a system where the type names follow a regular
pattern, and if you want to have a dozen distinct types the names are
clear and obvious. I have a few ideas, but since this will never
happen in any language called "C" I won't go into any more detail.

Isn't that why we now have (u)int32_t and friends? I tend to use int or
unsigned if I don't care about the size and one of the exact size type
if I do.

--
Ian Collins.

[Ian Collins]

Andrew Poelstra wrote:

On 2006-08-03, Keith Thompson <ks***@mib.orgw rote:

>>Richard Heathfield <in*****@invali d.invalidwrites :

>>>The introduction of long long int was, in my continued opinion, a mistake.
All the ISO guys had to do was - nothing at all! Any implementation that
wanted to support 64-bit integers could simply have made long int rather
longer than before - such a system would have continued to be fully
conforming to C90. And if it broke code, well, so what? Any code that
wrongly assumes long int is precisely 32 bits is already broken, and needs
fixing.

That's true, but 64 bits is the effective limit for this. The
following:
char 8 bits
short 16 bits
int 32 bits
long 64 bits
is a reasonable set of types, but if you go beyond that to 128 bits,
you're going to have to leave gaps (for example, there might not be
any 16-bit integer type).

1) This isn't really a problem; you can use a 32-bit variable to store
16-bit values; if you really need 16 bits you might need some debug
macros to artificially constrain the range.

Just beware of overflows!

2) If you've got a 128-bit processor, IMHO, you shouldn't be insisting
on using 8-bit types. That just sounds inefficient. [OT]

Unless your (possibly externally imposed) data happens to be 8 bit.

--
Ian Collins.

[Bill Pursell]

Andrew Poelstra wrote:

2) If you've got a 128-bit processor, IMHO, you shouldn't be insisting
on using 8-bit types. That just sounds inefficient. [OT]

Kind of an ironic statement in a thread about portability. :)

--
Bill Pursell

[Keith Thompson]

Andrew Poelstra <ap*******@fals e.sitewrites:

On 2006-08-03, Keith Thompson <ks***@mib.orgw rote:

>Richard Heathfield <in*****@invali d.invalidwrites :

>>The introduction of long long int was, in my continued opinion, a mistake.
All the ISO guys had to do was - nothing at all! Any implementation that
wanted to support 64-bit integers could simply have made long int rather
longer than before - such a system would have continued to be fully
conforming to C90. And if it broke code, well, so what? Any code that
wrongly assumes long int is precisely 32 bits is already broken, and needs
fixing.

That's true, but 64 bits is the effective limit for this. The
following:
char 8 bits
short 16 bits
int 32 bits
long 64 bits
is a reasonable set of types, but if you go beyond that to 128 bits,
you're going to have to leave gaps (for example, there might not be
any 16-bit integer type).

1) This isn't really a problem; you can use a 32-bit variable to store
16-bit values; if you really need 16 bits you might need some debug
macros to artificially constrain the range.

Yes, this was really a problem. The issue wasn't just the range, it
was the representation of an externally imposed data format.

2) If you've got a 128-bit processor, IMHO, you shouldn't be insisting
on using 8-bit types. That just sounds inefficient. [OT]

Unless, of course, you're doing string processing.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.