C99 portability challenge

[jacob navia]

Several people in this group argue that standard C
is not portable since there are no compilers for it, etc.

I propose this program in Standard C, that I have compiled
in several OSes to test if this is actually true. My
basic idea is to see which systems do not have a compiler that
supports standard C.

The program is designed to produce the sum of the natural
integers up to a user provider argument. For instance
the call
sum 55
should produce
The sum of the first 55 integers is 1540.

-----------------------------------------------cut here
#include <stdio.h>
#include <stdlib.h>
int main(int argc,char *argv[])
{
int sum=0;

if (argc < 2) {
printf("Usage: sum <number>\n");
return 1;
}

int top = atoi(argv[1]);

if (top <= 0)
return 0;
if (top > 100) {
printf("Maximum value 100. Enter a lower value\n");
return 1;
}

int vla[top];

for (int i=0; i<top;i++) {
vla = i+1;
}

for (int j = 0; j<top;j++) {
sum += vla[j];
}

printf("The sum of the first %d integers is %d\n",top,sum);
return 0;
}
------------------------------------------------cut here

I have already successfully compiled this program under

(1): windows using lcc-win.
(2): linux using gcc -std=c99
(3): AIX using xlc

I do not have any other type of system available. Please
if you have a system not listed above try to compile
this.

Thanks in advance.

 

[jacob navia]

Hello,

jacob navia wrote:

I have already successfully compiled this program under

(1): windows using lcc-win.
(2): linux using gcc -std=c99
(3): AIX using xlc

I do not have any other type of system available. Please
if you have a system not listed above try to compile
this.

Thanks in advance.

The application fails to compile on Windows using Visual Studio 2005 and
Visual Studio 2008.

When compiling using C mode (/TC) the application fails to compile due
to the declaration of 'int top', 'int i' and any other variable
declaration that is not at the beginning of the function. I believe this
is default C90 behavior.

When compiling using C++ mode (/TP) the application fails to compile due
to the declaration of 'int vla[top]' because 'top' is not a constant
expression and it is unable to create an array of constant size 0.

- Jensen

You can use Intel compiler within Visual studio, so C99 is supported
under windows. lcc-win also supports C99, and gcc (mingw) is used there
too, so the windows systems are sell served.

 

[Daniel Molina Wegener]

Several people in this group argue that standard C
is not portable since there are no compilers for it, etc.

I propose this program in Standard C, that I have compiled
in several OSes to test if this is actually true. My
basic idea is to see which systems do not have a compiler that
supports standard C.

The program is designed to produce the sum of the natural
integers up to a user provider argument. For instance
the call
        sum 55
should produce
The sum of the first 55 integers is 1540.

-----------------------------------------------cut here
#include <stdio.h>
#include <stdlib.h>
int main(int argc,char *argv[])
{
        int sum=0;

        if (argc < 2) {
                printf("Usage: sum <number>\n");
                return 1;
        }

        int top = atoi(argv[1]);

        if (top <= 0)
                return 0;
        if (top > 100) {
                printf("Maximum value 100. Enter a lower value\n");
                return 1;
        }

        int vla[top];

        for (int i=0; i<top;i++) {
                vla = i+1;
        }

        for (int j = 0; j<top;j++) {
                sum += vla[j];
        }

        printf("The sum of the first %d integers is %d\n",top,sum);
        return 0;}

------------------------------------------------cut here

I have already successfully compiled this program under

(1): windows using lcc-win.
(2): linux using gcc -std=c99
(3): AIX using xlc

I do not have any other type of system available. Please
if you have a system not listed above try to compile
this.

Thanks in advance.

I don't have access to my FreeBSD and Linux boxes,
but here I have an old version of gcc:

-----8<----------8<----------8<----------8<-----
[XXXXXXXX@XXXXXXX ~$] env LC_ALL=C gcc --version
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

[XXXXXXXX@XXXXXXX ~$] gcc -Wall -Wextra -Wshadow -pedantic -std=c99 -o
sum.exe sum.c
[XXXXXXXX@XXXXXXX ~$] gcc
gcc: no hay ficheros de entrada
-----8<----------8<----------8<----------8<-----

At night I will try with more compilers, I think that
gcc version 3.X it's a little bit old, I mean gcc 4.X
would have more strict warnings with the -pedantic
flags.

Regards,
DMW

 

[Rui Maciel]

The application fails to compile on Windows using Visual Studio 2005 and
Visual Studio 2008.

When compiling using C mode (/TC) the application fails to compile due
to the declaration of 'int top', 'int i' and any other variable
declaration that is not at the beginning of the function. I believe this
is default C90 behavior.

He did mentioned C99 in the subject line, which doesn't require that all
variable declarations should be restricted to the beginning of a function.

Why not try to compile the code with a decent, standard compliant
compiler?


Rui Maciel

 

[Rui Maciel]

The application fails to compile on Windows using Visual Studio 2005 and
Visual Studio 2008.

When compiling using C mode (/TC) the application fails to compile due
to the declaration of 'int top', 'int i' and any other variable
declaration that is not at the beginning of the function. I believe this
is default C90 behavior.

He did mentioned C99 in the subject line, which doesn't require that all
variable declarations should be restricted to the beginning of a function.

Why not try to compile the code with a decent, standard compliant
compiler?


Rui Maciel

 

[Keith Thompson]

Several people in this group argue that standard C
is not portable since there are no compilers for it, etc.

I propose this program in Standard C, that I have compiled
in several OSes to test if this is actually true. My
basic idea is to see which systems do not have a compiler that
supports standard C.

[snip]

See my response in comp.std.c.

 

[arnuld]

..SNIPPED ...
(1): windows using lcc-win.
(2): linux using gcc -std=c99
(3): AIX using xlc

(5): CentOS 4




[arnuld@dune programs]$ gcc -std=c99 -pedantic -Wall -Wextra C99-challenge.c
[arnuld@dune programs]$ ./a.out 3
The sum of the first 3 integers is 6
[arnuld@dune programs]$ gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-9)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


CentOS 4 is so old that it is not even supported by CentOS team itself

 

[Rui Maciel]

So you seem to be saying that C99 programs are portable to conforming
C99 compilers, is that right? What do you want us to do - hold the front
page?

Not quite. I pointed out that, as it is stated in the subject, the
standard being considered was C99, which, among other features, allows
variables to be defined in arbitrary places inside blocks.

Knowing that, I believe you can agree that all that sarcasm was uncalled
for.

As I understand it, the point (such as it is) of Jacob Navia's challenge
is to establish whether a rather naive little program that makes
undemanding use of a VLA is portable across a variety of not-quite-C99
implementations.

If he had written the program slightly differently:

then it would have been portable to *all* conforming hosted
implementations, C90 as well as C99 (as well as being faster and shorter
than his original). But that would have been beside his point.

If the intended purpose of Jacob Navia's challenge is to test C99's
portability then I don't understand the need to leave out any C99
feature. Wouldn't that defeat the purpose of this challenge?

Moreover, I do believe that it is more interesting and productive to test
C99's implementations (and also partial implementations) instead of C90.

He has
purposefully introduced non-portable features into the code with the
intent of demonstrating that they aren't really as non-portable as all
that, really.

Do you happen to mean "C99 features" instead of "non-portable features"?


Rui Maciel

 

[vippstar]

Several people in this group argue that standard C
is not portable since there are no compilers for it, etc.

They are all fools (note: I'm not insulting anyone, since nobody has
claimed _that_)
Standard C is not "portable" or "not portable". It's a language
standard.
What several people in this group say is that there isn't a C99
implementation yet.

I propose this program in Standard C, that I have compiled
in several OSes to test if this is actually true. My
basic idea is to see which systems do not have a compiler that
supports standard C.

Tests are meaningless.

 

[Flash Gordon]

jacob navia wrote, On 26/08/08 09:07:

Several people in this group argue that standard C
is not portable since there are no compilers for it, etc.

That is NOT what people are saying. They are saying there are
comparatively few C99 compilers.

I propose this program in Standard C, that I have compiled
in several OSes to test if this is actually true. My
basic idea is to see which systems do not have a compiler that
supports standard C.

SCO if you need to link against third party libraries built with the
OpenServer Development System (the officially provided by SCO gcc
version is 2.95 and GNU dropped support for SCO years ago for
philosophical reasons) is likely to have problems. I'm not going to boot
up my old SCO box just to test this though.

The program is designed to produce the sum of the natural
integers up to a user provider argument. For instance

So it only uses a small amount of C99. Here is another C99 program and
the output on my fully patched Ubuntu machine...
markg@brenda:~$ cat t.c
#include <stdio.h>
#include <math.h>

int main(void)
{
printf("%f\n",atan2(1,1));
}
markg@brenda:~$ gcc -std=c99 -pedantic -Wall -Wextra t.c
/tmp/cc8KagMH.o: In function `main':
t.c.text+0x1d): undefined reference to `atan2'
collect2: ld returned 1 exit status
markg@brenda:~$ cat /etc/issue
Ubuntu 8.04.1 \n \l

markg@brenda:~$ gcc --version
gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

markg@brenda:~$ /lib/libc.so.6
GNU C Library stable release version 2.7, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
Compiled on a Linux >>2.6.24-14-server<< system on 2008-04-04.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
markg@brenda:~$

I have already successfully compiled this program under

(1): windows using lcc-win.
(2): linux using gcc -std=c99
(3): AIX using xlc

Well, if you pick a program that builds on those three it will build on
those three. If you pick a different small simple C99 program it will
fail on at least one.

I do not have any other type of system available. Please
if you have a system not listed above try to compile
this.

You don't need more systems to see the problem, just a different program.

 

[jacob navia]

C99 features /are/ non-portable features. At present, anyway. Whether that
will change in the future is yet to be determined.

Strange

They run under
windows
Linux
AIX
Solaris
MacIntosh
IBM Mainframes

And they are not portable?

Obviously they are NOT portable because they will not run
in my washing machine.

 

[jacob navia]

(e-mail address removed) said:
[snip]

What several people in this group say is that there isn't a C99
implementation yet.

Some exist. Not many.

Heathfield!

This is a BIG progress!!!!

OK. OK. Now you acknowlezdge that C99 implepmentations DO exist.

This is a great progres for somebody like you that says:

<quote>
I don't need any evidence, because I know I'm right.
<end quote>

(dixit RH august 24th, 2008, 3:11 PM)

 

[Willem]

jacob navia wrote:
) Richard Heathfield wrote:
)>
)> C99 features /are/ non-portable features. At present, anyway. Whether that
)> will change in the future is yet to be determined.
)>
)
) Strange
)
) They run under
) windows
) Linux
) AIX
) Solaris
) MacIntosh
) IBM Mainframes
)
) And they are not portable?

The few features that you carefully chose, yes.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[jameskuyper]

(e-mail address removed) said:
[snip]

What several people in this group say is that there isn't a C99
implementation yet.

Some exist. Not many.

Heathfield!

This is a BIG progress!!!!

OK. OK. Now you acknowlezdge that C99 implepmentations DO exist.

He always acknowledged that conforming C99 implementations exist. If
you read his words a little more carefully you would have understood
that he was not claiming that they don't exist, merely that they are
so rare that most people have never actually seen one. I wish I could
say I was amazed that you've never noticed any of his frequent
acknowledgments of the existence but rarity of such compilers - but
I'm not.

A great many people have seen installations of compilers that almost
conform to C99, but his point was that installations of compilers with
modes that fully conform to C90 are much more common than
installations of compilers that have modes in which they fully conform
to C99.

 

[Lassie]

Several people in this group argue that standard C
is not portable since there are no compilers for it, etc.

I propose this program in Standard C, that I have compiled
in several OSes to test if this is actually true. My
basic idea is to see which systems do not have a compiler that
supports standard C.

Try this program:

#include <stddef.h>
#include <stdio.h>

void func(size_t n, char arr[*])
{
for (size_t i = 0; i < n; i++) printf("%c\n", arr);
}

int main(void)
{
char arr[4];
func(sizeof arr, arr);

return 0;
}

Or maybe make a program using *all* C99 features too with or without the
extra library functions.

 

[Keith Thompson]

Several people in this group argue that standard C
is not portable since there are no compilers for it, etc.

I propose this program in Standard C, that I have compiled
in several OSes to test if this is actually true. My
basic idea is to see which systems do not have a compiler that
supports standard C.

Try this program:

#include <stddef.h>
#include <stdio.h>

void func(size_t n, char arr[*])
{
for (size_t i = 0; i < n; i++) printf("%c\n", arr);
}

int main(void)
{
char arr[4];
func(sizeof arr, arr);

return 0;
}

Or maybe make a program using *all* C99 features too with or without
the extra library functions.

Suggestion: change
char arr[4];
to
char arr[4] = "abcd";
to avoid accessing uninitialized array elements. (There have been
debates about whether accessing uninitialized char objects invokes
undefined behavior, but it doesn't hurt to provide a program with
consistent output.)

Two data points:

gcc with "-std=c99", version 4.2.3, under x86 Ubuntu:

c.c:5: error: '[*]' not allowed in other than function prototype scope

Sun SPARC Solaris 9, Sun C 5.5:

Compiles without error, with my change produces correct output:
a
b
c
d

 

[vippstar]

(e-mail address removed) said:



It's really two language standards.

Indeed, but mr Navia has said in his previous posts that he refers to
the latest standard when saying "standard C"

Some exist. Not many.

Do you mean a *conforming* C99 implementation? Like, compiler and
library. If so, are you refering to comeau for example? Fine, then I'm
not sure what mr Navia is on about. If not, please elaborate.

 

[vippstar]

Suggestion: change
char arr[4];
to
char arr[4] = "abcd";
to avoid accessing uninitialized array elements. (There have been
debates about whether accessing uninitialized char objects invokes
undefined behavior, but it doesn't hurt to provide a program with
consistent output.)

Accessing uninitialized char object *does* invoke undefined behavior.
The debate was about _unsigned char_.

 

[dj3vande]

Eric Sosman said:

Richard Heathfield wrote:
It's really two language standards.
No, only one:

"This second edition *cancels and replaces* [emphasis mine]
the first edition, ISO/IEC 9899:1990,

Yes, someone should raise a DR for that, as it's obviously wrong.

Seriously, we do have two standards - the one we're supposed to use, and
the one everyone actually uses.

We "have" two Standards in the same way that you "have"
two Queen Elizabeths.

While correct, I'm not sure this actually addresses the subject at
hand.
When I say "C" in casual conversation, I mean the language defined by
ISO 9899:1990 (or, sometimes, that plus system-specific API calls).
When I say "Queen Elizabeth" in casual conversation, I mean the
currently reigning monarch.
So if we want to discuss what's actually happening in The Real World
(which we like to do on occasion, even in CLC), we basically have the
choice between rejecting the standard altogether or referring to the
earlier, officially superseded version. Of those two options, I know
which one I'd prefer.


dave

--
Dave Vandervies dj3vande at eskimo dot com

Autoresponder or illiteracy?

Let's just be charitable and say it's probably both.
--Shmuel Metz and Alan J Rosenthal in the scary devil monastery

 

[Richard Tobin]

We "have" two Standards in the same way that you "have"
two Queen Elizabeths.

Around here, we've only had one.

The pillar boxes, which in England read "E II R", read "E R" in Scotland.

-- Richard