473,854 Members | 1,457 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

code portability

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?
Aug 1 '06
239 10370
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.
Aug 4 '06 #41
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)
Aug 4 '06 #42
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.
Aug 4 '06 #43
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.
Aug 4 '06 #44
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
Aug 4 '06 #45
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
Aug 4 '06 #46
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.
Aug 4 '06 #47
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.
Aug 4 '06 #48

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

Aug 4 '06 #49
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.
Aug 4 '06 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
1848
by: Lefevre | last post by:
Hello. I recently discovered that this kind of code : | struct Object | { | string f() { return string("Toto"); } | } | | int main( ... )
0
9752
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11031
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10684
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10371
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
7918
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7082
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5744
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5942
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
3
3188
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.