473,854 Members | 1,523 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 10369
Al Balmer <al******@att.n etwrites:
On Wed, 02 Aug 2006 09:49:08 +0200, jacob navia
<ja***@jacob.re mcomp.frwrote:
[...]
>>You are just speaking nonsense. As specified here:

http://www.intel.com/cd/ids/develope...372.htm?page=4

the intel compiler complies with C99.

It doesn't say that at all. Did you actually read the article?
The table of compilation modes says:

-[no-]c99 C99 conformance and feature support
-std=c89 C89 conformance and feature support

I presume it conforms well to C89. The wording implies that it
conforms equally well to C99. My only reasons to doubt that are that
full C99 conformance is relatively rare, and I'd expect Intel to make
a bigger deal about it.

--
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 2 '06 #31
On Wed, 02 Aug 2006 21:00:26 +0200, jacob navia
<ja***@jacob.re mcomp.frwrote:
>Al Balmer wrote:
>On Wed, 02 Aug 2006 09:49:08 +0200, jacob navia
<ja***@jacob.r emcomp.frwrote:

>>>Tom St Denis a écrit :

Eigenvect or wrote:
>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
>attempte d to compile applications - such as gcc using my native Intel or xlC
>compiler s 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) .
You are just speaking nonsense. As specified here:

http://www.intel.com/cd/ids/develope...372.htm?page=4

the intel compiler complies with C99.


It doesn't say that at all. Did you actually read the article?

You can't read?

In that page the option
-std=c99
is mentioned with explanation:

" C99 conformance and feature support"
And that's what you're basing your conclusion on? An entry in a
options table? The name of one of the C++ options is "_strict_an si",
but in the text above, they tell you that the C++ compiler has only "a
high degree of conformance." IOW, it's not "strict ansi."

As one who claims to be a compiler vendor, you should know that
standards compliance should be supplied as a separate statement, along
with the required statement of implementation dependent behavior.

It's entirely possible that Intel is fully C99 compliant (though you'd
think they would say so in their ads), but you can't tell from the
page you gave us.
>
in the first table of that page.

And you say:

It doesn't say that at all. Did you actually read the article?

There is no blinder person as the one that doesn't want to see!

jacob
--
Al Balmer
Sun City, AZ
Aug 2 '06 #32
On Wed, 02 Aug 2006 18:58:00 GMT, Keith Thompson <ks***@mib.or g>
wrote:
>Al Balmer <al******@att.n etwrites:
>On Wed, 02 Aug 2006 09:49:08 +0200, jacob navia
<ja***@jacob.r emcomp.frwrote:
[...]
>>>You are just speaking nonsense. As specified here:

http://www.intel.com/cd/ids/develope...372.htm?page=4

the intel compiler complies with C99.

It doesn't say that at all. Did you actually read the article?

The table of compilation modes says:

-[no-]c99 C99 conformance and feature support
-std=c89 C89 conformance and feature support

I presume it conforms well to C89.
An unjustified presumption, imo. The text does claim good conformance
to the C++ standard, but really says nothing about either C89 or C99
conformance.
The wording implies that it
conforms equally well to C99.
Or equally badly, if you mean the wording in the table of compilation
modes, which probably isn't legally binding :-)
My only reasons to doubt that are that
full C99 conformance is relatively rare, and I'd expect Intel to make
a bigger deal about it.
Fourth return from Google:
http://www.intel.com/support/perform.../cs-015003.htm

<quote>
C Standard Conformance
The Intel® C++ Compilers provide some conformance to the ANSI/ISO
standard for C language compilation (ISO/IEC 9899:1999).

For more information on C conformance, refer to the User's Guide.
</quote>

I expect the user's guide will have a detailed listing of
non-conforming items, as well as the list of implementation-dependent
items.

--
Al Balmer
Sun City, AZ
Aug 2 '06 #33
Al Balmer <al******@att.n etwrites:
On Wed, 02 Aug 2006 18:58:00 GMT, Keith Thompson <ks***@mib.or g>
wrote:
[...]
>>The table of compilation modes says:

-[no-]c99 C99 conformance and feature support
-std=c89 C89 conformance and feature support

I presume it conforms well to C89.

An unjustified presumption, imo. The text does claim good conformance
to the C++ standard, but really says nothing about either C89 or C99
conformance.
Perhaps. My presumption is based largely on the fact that C89
conformance is much easier to achieve than C99 or C++ conformance.
There are plenty of compilers that conform well to the C89/C90
standard; Intel's compiler would have trouble competing if it had
significant gaps.

This is, of course, guesswork based on circumstantial evidence, not
guaranteed to be worth more than you paid for it.

--
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 2 '06 #34

<we******@gmail .comwrote in message
news:11******** **************@ m79g2000cwm.goo glegroups.com.. .
Eigenvector wrote:
>[...] I fully realize that
independent developers may or may not conform to standards, but again is
it
at least encouraged?

Not really. By its very nature C encourages non-portable programming.
In general, I try to write code portably, but the only thing keeping me
honest is actually compiling my stuff with multiple compilers to see
what happens.
Yes. There is a tension between efficiency and portability. In Java they
resolved it by compromising efficiency, in C we have to be careful to make
our portable code genuinely portable, which is why the topic is so often
discussed.
There is also the problem of "good enough" portability, for instance
assuming ASCII and two's complement integers.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

Aug 3 '06 #35
Websnarf posted:
Not really. By its very nature C encourages non-portable programming.

Heavily subjective statement, and I disagree vehemently.
In general, I try to write code portably, but the only thing keeping me
honest is actually compiling my stuff with multiple compilers to see
what happens.

Without trying to sound condescending: You should have a better knowledge
of the restrictions (and freedoms) which the C Standard imposes upon
implementations . Things like:

(1) Null pointers need not be all bits zero.
(2) All bits zero must be a valid zero value for an integer type.
(3) All union members have the same address.
(4) There may be padding between struct elements.

I NEVER have to rely on different compiler tests to tell me if my code is
portable -- I just look for the relevant excerpt from the Standard.
To be completely portable, you also have to support multiple bit sizes
for int

Easily sorted with:

(1) sizeof
(2) IMAX_BITS written by Hallvard B Furuseth
>, be wary of arbitrary call order of parameters or expression
operands,

Don't rely on order of evaluation. The language has sequence points for a
reason.
use char as either signed
or unsigned,

Only use "plain char" to store a character -- don't use it for numbers or
arithmetic.
and allow for non-2s complement integers.

When would one need to reply on having 2's complement? It would only be
relevant if you're doing bit-fiddling. In any case, you an easily make
allowances for it:

#if (-1 & 3 == ...
#define TWOS_COMPLEMENT ...
#else
#define ONES_COMPLEMENT ...

And... if all else fails, and your program simply MUST run on a two's
complement system, then:

#ifndef TWOS_COMPLEMENT
#error ...
The problem is that its hard to find a compiler or platforms that
supports variation in those things.

But it's easy to find the relevant paragraphs in the Standard.
The easy way to make C code "portable" is to lower your standards for
portability. I.e., just port your code to major compilers (MSVC, gcc
and some Unix cc -- personally, I add Borland C, Turbo C and Watcom C
when I want to really push it), and hope that's good enough.

Better yet... just write 100% portable Standard-compliant code.
In general writing any non-trivial amount of code in C for which you
have good certainty about portability is really quite time consuming.

Not if you're familiar with writing portable code.
The "open source community" tends to favor "make it work" over "make it
portable".

If the Open Source Community jumped off a cliff, would you ju...

--

Frederick Gotham
Aug 3 '06 #36
"Malcolm" <re*******@btin ternet.comwrite s:
<we******@gmail .comwrote in message
news:11******** **************@ m79g2000cwm.goo glegroups.com.. .
>Eigenvector wrote:
>>[...] I fully realize that
independent developers may or may not conform to standards, but again is
it
at least encouraged?

Not really. By its very nature C encourages non-portable programming.
In general, I try to write code portably, but the only thing keeping me
honest is actually compiling my stuff with multiple compilers to see
what happens.
Yes. There is a tension between efficiency and portability. In Java they
resolved it by compromising efficiency, in C we have to be careful to make
our portable code genuinely portable, which is why the topic is so often
discussed.
There is also the problem of "good enough" portability, for instance
assuming ASCII and two's complement integers.
I rarely find it useful to assume ASCII. It's usually just as easy to
write code that depends only on the guarantees in the standard, and
will just work regardless of the character set. It would be
marginally more convenient to be able to assume that the character
codes for the letters are contiguous, but that's easy enough to work
around.

As for two's complement, I typically don't care about that either.
Numbers are numbers. If I need to do bit-twiddling, I use unsigned.

--
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 3 '06 #37
Keith Thompson said:
"Malcolm" <re*******@btin ternet.comwrite s:
<snip>
>There is also the problem of "good enough" portability, for instance
assuming ASCII and two's complement integers.

I rarely find it useful to assume ASCII. It's usually just as easy to
write code that depends only on the guarantees in the standard, and
will just work regardless of the character set. It would be
marginally more convenient to be able to assume that the character
codes for the letters are contiguous, but that's easy enough to work
around.
I suppose that this attitude is more natural for those of us who have
written code that has to work on real live non-ASCII systems, simply
because we're so used to not being /able/ to assume ASCII that it never
occurs to us to rely on ASCII even when we might get away with it.
As for two's complement, I typically don't care about that either.
Numbers are numbers. If I need to do bit-twiddling, I use unsigned.
Indeed. And, on a related note, I find it very difficult to understand this
fascination with integers that have a particular number of bits. If I need
8 bits, I'll use char (or a flavour thereof). If I need 9 to 16 bits, I'll
use int (or unsigned). If I need 17 to 32 bits, I'll use long (or unsigned
long). And if I need more than 32 bits, I'll use a bit array. I see
absolutely no need for int_leastthis, int_fastthat, and int_exacttheoth er.

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.

--
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 3 '06 #38
Richard Heathfield <in*****@invali d.invalidwrites :
Keith Thompson said:
>"Malcolm" <re*******@btin ternet.comwrite s:

<snip>
>>There is also the problem of "good enough" portability, for instance
assuming ASCII and two's complement integers.

I rarely find it useful to assume ASCII. It's usually just as easy to
write code that depends only on the guarantees in the standard, and
will just work regardless of the character set. It would be
marginally more convenient to be able to assume that the character
codes for the letters are contiguous, but that's easy enough to work
around.

I suppose that this attitude is more natural for those of us who have
written code that has to work on real live non-ASCII systems, simply
because we're so used to not being /able/ to assume ASCII that it never
occurs to us to rely on ASCII even when we might get away with it.
Perhaps, but I've never really programmed for a non-ASCII system.

It just wouldn't occur to me to write code that depends on the
assumption that 'A' == 65. If I want 'A', I write 'A'.
>As for two's complement, I typically don't care about that either.
Numbers are numbers. If I need to do bit-twiddling, I use unsigned.

Indeed. And, on a related note, I find it very difficult to understand this
fascination with integers that have a particular number of bits. If I need
8 bits, I'll use char (or a flavour thereof). If I need 9 to 16 bits, I'll
use int (or unsigned). If I need 17 to 32 bits, I'll use long (or unsigned
long). And if I need more than 32 bits, I'll use a bit array. I see
absolutely no need for int_leastthis, int_fastthat, and int_exacttheoth er.
But there are times when you need some exact number of bits,
particularly when you're using an externally imposed data format.
(But then whoever is imposing the data format on you should have
provided a header that declares the appropriate types.)

Something that might be more useful would be a way to ask for an
integer type with (at least) a specified *range*. If I'm using a type
to hold numbers rather than bags of bits, I care what numbers I can
store in it, not how many bits it uses to store them.
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).

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.

--
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 3 '06 #39
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
implementati on 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?
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,
I think the C99 guys missed a trick by not reserving "very" for this
purpose. If they must spec extra types, at least make them scalable:

very long - at least 64 bits
very very long - at least 128 bits
very very very long - at least 256 bits
etc

--
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 #40

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
10682
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...
1
10761
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
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...
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
5743
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?
1
4563
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4159
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3187
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.