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] = 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
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Jensen Somers wrote:

Hello,

jacob navia wrote:

<snip>

>>
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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Pietro Cerutti]

jacob navia wrote:

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] = 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

(4): FreeBSD using gcc -std=c99
--
Pietro Cerutti

[Daniel Molina Wegener]

On Aug 26, 4:07*am, jacob navia <[e-mail]:

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] = 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
jacob at jacob point remcomp point fr
logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32

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]

On Tue, 26 Aug 2008 10:28:14 +0200, Jensen Somers wrote:

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

[Richard Heathfield]

Rui Maciel said:

On Tue, 26 Aug 2008 10:28:14 +0200, Jensen Somers wrote:

>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?

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?

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:

#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
int rc = EXIT_SUCCESS;

unsigned long n = argc 1 ? strtoul(argv[1], NULL, 10) : 0;
if(n 0 && n <= 100)
{
printf("The sum of the first %lu integers is %lu\n",
n, n * (n + 1) / 2);
}
else
{
puts("Please use an argument in the range 1 to 100 inclusive.");
rc = EXIT_FAILURE;
}
return rc;
}

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. 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. How far he has succeeded is rather questionable, since his
code steps around many C99 conformance issues.

(Frankly, I'd rather use the shorter, faster, more portable version, but
YMMV.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Rui Maciel]

On Tue, 26 Aug 2008 10:28:14 +0200, Jensen Somers wrote:

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]

On Tue, 26 Aug 2008 16:21:58 +0000, Richard Heathfield wrote:

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:

<snip />

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]

On Aug 26, 11:07 am, jacob navia <[e-mail]:

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:~$

<snip>

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.
--
Flash Gordon

[Richard Heathfield]

Rui Maciel said:

On Tue, 26 Aug 2008 16:21:58 +0000, Richard Heathfield wrote:

>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.

Yes, I understand that. But you said "Why not try to compile the code with
a decent, standard compliant compiler?" Now, any C99-conforming compiler
*must* translate the code properly, making the challenge rather moot.
Nobody denies that C99-conforming implementations must translate C99 code
properly; if that's what Jacob Navia intended to prove, it was a pretty
stupid challenge. No, I think he's trying to demonstrate that a program
that exhibits C99 features is translatable with correct semantics by a
large number of modern compilers, whether or not they are C99-conforming.
That is, he is hoping to test the portability of C99 code, not the
existence of C99 implementations.

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

My reply didn't contain much sarcasm, just a little. You can try for more
if you like - I have plenty left.

<snip>

>If he had written the program slightly differently:

<snip />

>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?

Yes - you repeat me: "But that would have been beside his point."

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

I found it fascinating how easily one could take a simple, clean, portable
task and turn it into a non-portable mess.

>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"?

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

vi******@gmail.com said:

On Aug 26, 11:07 am, jacob navia <[e-mail]:

>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.

It's really two language standards. :-)

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

Some exist. Not many.

>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.

This particular test (which in any case only covers VLAs and mixed decs) is
meaningless, since it doesn't provide an exhaustive exercising of VLA
semantics.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

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?

Obviously they are NOT portable because they will not run
in my washing machine.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Richard Heathfield wrote:

vi******@gmail.com 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!!!!

Just yesterday you wrote:

> Have *you* ever encountered a
conforming C99 installation? Even one?

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)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[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]

jacob navia wrote:

Richard Heathfield wrote:

vi******@gmail.com 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!!!!

Just yesterday you wrote:

> Have *you* ever encountered a
>conforming C99 installation? Even one?

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.

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>vi******@gmail.com 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!!!!

No, it's perfectly consistent with what I've said before.

Just yesterday you wrote:

> Have *you* ever encountered a
>conforming C99 installation? Even one?

You read without understanding, and reply without thought.

<rest of nonsense snipped>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Eric Sosman]

Richard Heathfield wrote:

vi******@gmail.com said:

>On Aug 26, 11:07 am, jacob navia <[e-mail]:

>>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.

It's really two language standards. :-)

No, only one:

"This second edition *cancels and replaces* [emphasis mine]
the first edition, ISO/IEC 9899:1990, as amended and corrected
by ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and ISO/IEC
9899/COR2:1996. [...]"[*]

Or to put it another way, "The Standard is dead; long live
the Standard!"
[*] Determining whether the quoted paragraph has any meaning
at all is left as an exercise in futility.

--
Er*********@sun.com

[Lassie]

"jacob navia" <ja***@nospam.comschreef in bericht
news:g9**********@aioe.org...

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[i]);
}

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.

[Richard Heathfield]

Eric Sosman said:

Richard Heathfield wrote:

>vi******@gmail.com said:

<snip>

>>Standard C is not "portable" or "not portable". It's a language
standard.

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Eric Sosman]

Richard Heathfield wrote:

Eric Sosman said:

>Richard Heathfield wrote:

>>vi******@gmail.com said:

<snip>

>>>Standard C is not "portable" or "not portable". It's a language
standard.
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.

--
Er*********@sun.com

[Keith Thompson]

"Lassie" <zh*@woaini.comwrites:

"jacob navia" <ja***@nospam.comschreef in bericht
news:g9**********@aioe.org...

>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[i]);
}

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[vippstar]

On Aug 26, 10:28 pm, Richard Heathfield <[e-mail]:

[e-mail] said:

On Aug 26, 11:07 am, jacob navia <[e-mail]:

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.

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"

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

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]

On Aug 26, 11:54 pm, Keith Thompson <[e-mail]:

<snip>

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]

In article <1219783669.121971@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:

>Richard Heathfield wrote:

>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]

In article <1219783669.121971@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:

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
--
Please remember to mention me / in tapes you leave behind.

[Antoninus Twink]

On 26 Aug 2008 at 18:52, Flash Gordon wrote:

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

Compiles fine on my current Debian system.

You have proved to the world that your machine has an obsolete
development environment, nothing more, nothing less.

[Richard Heathfield]

vi******@gmail.com said:

On Aug 26, 10:28 pm, Richard Heathfield <[e-mail]:

>[e-mail] said:

On Aug 26, 11:07 am, jacob navia <[e-mail]:
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.

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"

Yes, I know, and I take that into account when reading Mr Navia's articles,
because (believe it or not) I do take the trouble to try to work out what
he means by what he writes. This thread is perhaps a good example - I
think I've got a reasonable idea of what he's trying to do; I don't
necessarily agree that it's a great idea, but at least I *understand* it,
whereas I think there are some others who don't.

>

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

Some exist. Not many.

Do you mean a *conforming* C99 implementation?

I see no distinction between "C99 implementation" and "conforming C99
implementation". If it doesn't conform to C99, I don't consider it an
implementation of C99.

Like, compiler and
library. If so, are you refering to comeau for example?

I am unsure whether Greg still claims conformance for C99. He did once, but
my understanding is that he modded the claim down to "support". Perhaps
Greg could clarify for us. (I may have asked him this before, and he may
even have answered, but hey, I can't remember everything.)

Fine, then I'm
not sure what mr Navia is on about. If not, please elaborate.

What I think Jacob Navia is trying to show - and it's a perfectly
reasonable thing to try, I hasten to add - is that a typical C program
that uses typical C99 constructs (in what we might call a vanilla,
non-destruct-test way) is portable *not only* among implementations that
*conform* to C99 - which of course it must be, by definition - but *also*
among implementations that merely "support" C99 - such as gcc, for
example.

I don't actually agree that the experiment will tell us very much that is
useful (for reasons which I can explain fully if anyone cares enough), but
I'm reasonably sure that I have accurately described his intent.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Bacarisse]

"Lassie" <zh*@woaini.comwrites:

"jacob navia" <ja***@nospam.comschreef in bericht
news:g9**********@aioe.org...

>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[*])

This form is not allowed in a function definition. It is not a
constraint violation, so no diagnostic is required. I am not 100%
sure of the status of a program that breaks a rule that is phrased as
this one is:

6.7.5.2p4:

If the size is * instead of being an expression, the array type a
variable length array type of unspecified size, which can only be
used in declarations with function prototype scope;124) such arrays
are nonetheless complete types.

(Footnote 124 says: Thus, * can be used only in function declarations
that are not definitions (see 6.7.5.3))

--
Ben.

[Anand Hariharan]

On Aug 26, 3:07*am, jacob navia <[e-mail]:

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.

(...)

>
Thanks in advance.

I wish you didn't multi-post. Had Keith Thompson not hinted that you
had posted in comp.std.c as well, I would have missed posts there (I
don't follow that group at all).

I think Charlie Gordon's post in that group was a very balanced
critique of your program, and he makes some valid suggestions on how
you can extend your test to truly ascertain what you want to find.

- Anand

[vippstar]

On Aug 27, 6:19 am, Anand Hariharan <[e-mail]>
wrote:

On Aug 26, 3:07 am, jacob navia <[e-mail]:

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.

(...)

Thanks in advance.

I wish you didn't multi-post. Had Keith Thompson not hinted that you
had posted in comp.std.c as well, I would have missed posts there (I
don't follow that group at all).

Not only he multi-posted, but it's off-topic in comp.std.c
(note: he said "in this group" and he multi-posted that message...)

[arnuld]

On Tue, 26 Aug 2008 10:07:42 +0200, jacob navia wrote:

..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 ;)

--
www.lispmachine.wordpress.com
my email is @ the above blog.Google Groups is Blocked. Reason: Excessive Spamming

[Nick Keighley]

On 26 Aug, 17:21, Richard Heathfield <[e-mail]:

Rui Maciel said:

On Tue, 26 Aug 2008 10:28:14 +0200, Jensen Somers wrote:

[C99 program] 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?

begging the question

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?

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.

I don't think its unreasonable to produce some sort of basic
validation test case for C99. Of course Jacob's program
falls *way* short of being that.

If he had written the program slightly differently:

#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
* int rc = EXIT_SUCCESS;

* unsigned long n = argc 1 ? strtoul(argv[1], NULL, 10) : 0;
* if(n 0 && n <= 100)
* {
* * printf("The sum of the first %lu integers is %lu\n",
* * * * * *n, n * (n + 1) / 2);
* }
* else
* {
* * puts("Please use an argument in the range 1 to 100 inclusive.");
* * rc = EXIT_FAILURE;
* }
* return rc;

}

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).

um. and not a test of C99 implementations (using "implementation" in
its
weak form).

But that would have been beside his point. 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. How far he has succeeded is rather questionable, since his
code steps around many C99 conformance issues.

(Frankly, I'd rather use the shorter, faster, more portable version, but
YMMV.)

but that misses the point.

Doesn't C99 have rather more new features than mixing declarations
with statments and VLAs?
--
Nick Keighley

"an easy to use computer should do what I mean, not what I say,
and by no means send me a dancing paper clip to ask"
Nicholas Negroponte (MIT Professor)

[Nick Keighley]

On 26 Aug, 19:38, [e-mail] wrote:

On Aug 26, 11:07 am, jacob navia <[e-mail]:

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

many people claim that C99 programs are not very portable
because few implementaion of C99 exist.

Are there *any* embedded implentations of C99?

<snip>

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.

so how can *any* implementation of any language
claim to be conformant with any standard?

Do the implementors submit proofs of correctness?

No, they use a validation suite of some sort.

(oh course Jacob's program *very* isn't a validation suite}

--
Nick Keighley

"Remember, the TAB key is your friend!"
Computer Training at [Large Financial Company]

[Nick Keighley]

On 26 Aug, 23:40, Richard Heathfield <[e-mail]:

<snip>

What I think Jacob Navia is trying to show - and it's a perfectly
reasonable thing to try, I hasten to add - is that a typical C program
that uses typical C99 constructs (in what we might call a vanilla,
non-destruct-test way) is portable *not only* among implementations that
*conform* to C99 - which of course it must be, by definition - but *also*
among implementations that merely "support" C99 - such as gcc, for
example.

I don't actually agree that the experiment will tell us very much that is
useful (for reasons which I can explain fully if anyone cares enough)

go on then.

wouldn't a well defined, moderatly portable subset of C99 be a useful
thing to have?

<snip>
--
Nick Keighley

Testing can show the presense of bugs, but not their absence.
-- Dijkstra

[jacob navia]

vi******@gmail.com wrote:

On Aug 27, 6:19 am, Anand Hariharan <[e-mail]>
wrote:

>On Aug 26, 3:07 am, jacob navia <[e-mail]:

>>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.

(...)

>>Thanks in advance.

I wish you didn't multi-post. Had Keith Thompson not hinted that you
had posted in comp.std.c as well, I would have missed posts there (I
don't follow that group at all).

Not only he multi-posted, but it's off-topic in comp.std.c
(note: he said "in this group" and he multi-posted that message...)

I did NOT multi post, and if you read comp.std.c you will
see that the messages are different.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[vippstar]

On Aug 27, 12:53 pm, jacob navia <[e-mail]:

[e-mail] wrote:

On Aug 27, 6:19 am, Anand Hariharan <[e-mail]>
wrote:

On Aug 26, 3:07 am, jacob navia <[e-mail]:

>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.
(...)

>Thanks in advance.
I wish you didn't multi-post. Had Keith Thompson not hinted that you
had posted in comp.std.c as well, I would have missed posts there (I
don't follow that group at all).

Not only he multi-posted, but it's off-topic in comp.std.c
(note: he said "in this group" and he multi-posted that message...)

I did NOT multi post, and if you read comp.std.c you will
see that the messages are different.

Oh yeah, you are right, I'm sorry. The messages are indeed different.
(their hash might differ; in essence they are the same; multi-post for
me)
Your message in comp.std.c is _STILL_ off-topic for that group.

[Richard Heathfield]

Nick Keighley said:

On 26 Aug, 17:21, Richard Heathfield <[e-mail]:

>Rui Maciel said:

<snip>

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

begging the question

Precisely.

>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?

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.

I don't think its unreasonable to produce some sort of basic
validation test case for C99.

No, of course it isn't unreasonable.

Of course Jacob's program falls *way* short of being that.

I don't think that was his intent.

>If he had written the program slightly differently:

[C90 version snipped]

>>
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).

um. and not a test of C99 implementations (using "implementation" in
its weak form).

Yes, I know, but his program wasn't much cop at that either.

>But that would have been beside his point. [...]

(Frankly, I'd rather use the shorter, faster, more portable version, but
YMMV.)

but that misses the point.

Yes, it would have been beside his point (he said again).

Doesn't C99 have rather more new features than mixing declarations
with statments and VLAs?

Apparently not. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Nick Keighley said:

On 26 Aug, 23:40, Richard Heathfield <[e-mail]:

<snip>

>I don't actually agree that the experiment will tell us very much that
is useful (for reasons which I can explain fully if anyone cares enough)

go on then.

<sighI'd have thought you'd know this already. Fortunately, I've found an
easy way to explain it.

Let's just imagine a world in which Jacob Navia's test program can be
compiled on a dozen different compilers that offer "support" for C99, with
the right semantics and everything. What does that tell us about the
portability of *this* program (which, as far as I'm aware, is legal C99,
although obviously I haven't tried it because I don't have a C99
implementation):

#include <stdio.h>
#include <math.h>
struct vector { double x; double y; };
double vector_length(const struct vector *p)
{
return sqrt(p->x * p->x + p->y * p->y);
}
int main(void)
{
printf("%f\n", vector_length(&(const struct point){.x=3.0,.y=4.0}));
return 0;
}

? And of course the answer is that it doesn't tell us anything at all.

wouldn't a well defined, moderatly portable subset of C99 be a useful
thing to have?

Sure. We could call it "C90".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

Nick Keighley said:

>On 26 Aug, 23:40, Richard Heathfield <[e-mail]:

<snip>

>>I don't actually agree that the experiment will tell us very much that
is useful (for reasons which I can explain fully if anyone cares enough)

go on then.

<sighI'd have thought you'd know this already. Fortunately, I've found an
easy way to explain it.

Let's just imagine a world in which Jacob Navia's test program can be
compiled on a dozen different compilers that offer "support" for C99, with
the right semantics and everything. What does that tell us about the
portability of *this* program (which, as far as I'm aware, is legal C99,
although obviously I haven't tried it because I don't have a C99
implementation):

#include <stdio.h>
#include <math.h>
struct vector { double x; double y; };
double vector_length(const struct vector *p)
{
return sqrt(p->x * p->x + p->y * p->y);
}
int main(void)
{
printf("%f\n", vector_length(&(const struct point){.x=3.0,.y=4.0}));
return 0;
}

? And of course the answer is that it doesn't tell us anything at all.

Well, it could tell us something if you would get rid of the
errors to begin with...

PTOTBBC!!!!

(Please Turn On The Brain Before Coding)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:bf******************************@bt.com...

Nick Keighley said:

>wouldn't a well defined, moderatly portable subset of C99 be a useful
thing to have?

Sure. We could call it "C90".

Suppose C99 offered 1000 extra features over C90.

How many of those 1000 features would have to be fully implemented for a
valid C99 implementation? All of them?

So you wouldn't even use 1 useful C99 feature, because a particular
implementation only manages 998 of the rest?

(I'd imagine such an attibute would be quite dispiriting to any C99
developers; they can nearly kill themselves getting 997 of the 1000 in
place, but that might as well be 0 out of 1000 as far as some people are
concerned.)

Let's look at just one C99 feature, being able to declare ints with a
guaranteed 64 bits. That makes sense to have, for someone programming 64
bits, especially on 64-bit-capable hardware.

This seems to be available on several C compilers that are not considered
(especially by you) to be C99-capable.

Is someone using such an extension, using effectively a small subset of C99?

It seems to me a good idea, when using extensions, to use those which are
part of C99, even if your current compiler is not C99. Then your code can be
portable to other compilers whice /are/ C99, or which implement a subset of
C99 which is a superset of yours.

In this case C99 does become useful now, even if you have no full
implementation to hand. It will give encouragement to C99 compiler
developers, because there will be code around using C99 features, and
therefore there will be a demand for compilers which implement at least that
subset.

And, you get the benefit of those extra features!

So Nick's suggestion for there to exist a well-defined set of C99 features,
that are an /enhancement/ to C90, sounds good. Better than everyone using
ad-hoc extensions to their compilers.

--
Bartc

[Ben Bacarisse]

jacob navia <ja***@nospam.comwrites:

Richard Heathfield wrote:

>Nick Keighley said:

>>On 26 Aug, 23:40, Richard Heathfield <[e-mail]:

<snip>

>>>I don't actually agree that the experiment will tell us very much that
is useful (for reasons which I can explain fully if anyone cares enough)
go on then.

<sighI'd have thought you'd know this already. Fortunately, I've
found an easy way to explain it.

Let's just imagine a world in which Jacob Navia's test program can
be compiled on a dozen different compilers that offer "support" for
C99, with the right semantics and everything. What does that tell us
about the portability of *this* program (which, as far as I'm aware,
is legal C99, although obviously I haven't tried it because I don't
have a C99 implementation):

#include <stdio.h>
#include <math.h>
struct vector { double x; double y; };
double vector_length(const struct vector *p)
{
return sqrt(p->x * p->x + p->y * p->y);
}
int main(void)
{
printf("%f\n", vector_length(&(const struct point){.x=3.0,.y=4.0}));
return 0;
}

? And of course the answer is that it doesn't tell us anything at all.

Well, it could tell us something if you would get rid of the
errors to begin with...

One typo. Presumably you are grateful for that typo since the
corrected version gives 12 compile errors with lcc-win32.

Does lcc-win32 compile the VLA example I posted in reply to your
suggestion that C99 is portable? Personally, I think C99 is
reasonably portable for some application domains provided one avoids
lcc-win32, at least for the moment. The problems with designated
initialisers, compound literals, VLAs, variable macro argument lists
and non-constant initialisations make it too fragile.

I have no problem with your decision to implement extensions before
C99 features (it probably makes commercial sense given that, on
Windows, the dominant compiler vendor is not interested in C99) but it
sits oddly with your apparent passion for C99 here.

--
Ben.

[Richard Heathfield]

Ben Bacarisse said:

jacob navia <ja***@nospam.comwrites:

>Richard Heathfield wrote:

>>Nick Keighley said:

On 26 Aug, 23:40, Richard Heathfield <[e-mail]:
<snip>

I don't actually agree that the experiment will tell us very much
that is useful (for reasons which I can explain fully if anyone cares
enough)
go on then.

<sighI'd have thought you'd know this already. Fortunately, I've
found an easy way to explain it.

Let's just imagine a world in which Jacob Navia's test program can
be compiled on a dozen different compilers that offer "support" for
C99, with the right semantics and everything. What does that tell us
about the portability of *this* program (which, as far as I'm aware,
is legal C99, although obviously I haven't tried it because I don't
have a C99 implementation):

#include <stdio.h>
#include <math.h>
struct vector { double x; double y; };
double vector_length(const struct vector *p)
{
return sqrt(p->x * p->x + p->y * p->y);
}
int main(void)
{
printf("%f\n", vector_length(&(const struct point){.x=3.0,.y=4.0}));
return 0;
}

? And of course the answer is that it doesn't tell us anything at all.

Well, it could tell us something if you would get rid of the
errors to begin with...

One typo.

Oh, I see it now. I said "point" instead of "vector", didn't I? LACKING A
C99 COMPILER, I was unable to compile it.

Presumably you are grateful for that typo since the
corrected version gives 12 compile errors with lcc-win32.

Wow - Jacob was right; it did tell us something after all.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Bartc said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:bf******************************@bt.com...

>Nick Keighley said:

>>wouldn't a well defined, moderatly portable subset of C99 be a useful
thing to have?

Sure. We could call it "C90".

Suppose C99 offered 1000 extra features over C90.

How many of those 1000 features would have to be fully implemented for a
valid C99 implementation? All of them?

Yes.

So you wouldn't even use 1 useful C99 feature, because a particular
implementation only manages 998 of the rest?

It depends on your goals. If you don't know in advance on which
implementations your program is expected to work, you can't be sure that
the subset of features you use is supported by all the implementations.

Never mind a thousand - let's try six. We'll call them P Q R S T U.

Implementation Features supported
A P Q S T U
B P Q R T
C P Q T U
D P R S U
E P Q R S U
F P R S T
G ? ? ? ? ? ?

A program that uses feature P is portable across implementations A through
F. If those are the only implementations you're ever going to use, great -
you can use feature P. (Of course, if you need portability across six
platforms, there's a strong possibility that you'll eventually need it
across a seventh, an eighth, a ninth... but never mind that for now.)

A program that uses feature Q is only portable across A, B, C, and E. If
that's sufficient for your needs, fine.

A program that uses feature S is only portable across A, D, E, and F.

A program that uses feature Q AND feature S is only portable across A and
E.

A program that uses Q, S, and T will *only* work on A.

And of course there's G to consider. G is an implementation about which we
know very little, or nothing, except that it is a conforming C90
implementation with, perhaps, additional support for C99 (or perhaps not).
Most people don't seem to worry a great deal about G - but whenever we
write C on this newsgroup that is not specifically tagged as being for a
particular implementation (and therefore, according to some, off-topic
anyay), we are writing for Implementation G - the Unknown Implementation.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:L8*********************@bt.com...

Bartc said:

>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:bf******************************@bt.com...

>>Nick Keighley said:

>>>wouldn't a well defined, moderatly portable subset of C99 be a useful
thing to have?

Sure. We could call it "C90".

Suppose C99 offered 1000 extra features over C90.

How many of those 1000 features would have to be fully implemented for a
valid C99 implementation? All of them?

.....

It depends on your goals. If you don't know in advance on which
implementations your program is expected to work, you can't be sure that
the subset of features you use is supported by all the implementations.

Never mind a thousand - let's try six. We'll call them P Q R S T U.

Implementation Features supported
A P Q S T U
B P Q R T
C P Q T U
D P R S U
E P Q R S U
F P R S T
G ? ? ? ? ? ?

Seems a 'well-defined subset of C99' is still a good idea.

Which subset this should be is hard to tell from your example: there are 4
implementations of each feature apart from P.

I would go with the easiest to implement and/or those which already exist
anyway. It might be there is already a subset implemented across many
compilers, for example //-comments and long-long-int. That would at least be
a start, and require little effort. Eg. the subset [P] in your example.

And for platforms for which there is only G, and there exists a good reason
to port your code to that platform, then the customers of that platform
should demand a [P]-compliant compiler. Otherwise why should G stifle the
development and progress of all the others?

--
Bartc

[Richard Heathfield]

Bartc said:

<snip>

And for platforms for which there is only G, and there exists a good
reason to port your code to that platform, then the customers of that
platform should demand a [P]-compliant compiler. Otherwise why should G
stifle the development and progress of all the others?

I accept that there are examples of people telling their customers what to
do, what to use, even what to think, and still getting rich. Nevertheless,
it isn't a strategy with which I am comfortable.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

"Bartc" <[e-mail]:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:L8*********************@bt.com...

[...]

>It depends on your goals. If you don't know in advance on which
implementations your program is expected to work, you can't be sure that
the subset of features you use is supported by all the implementations.

Never mind a thousand - let's try six. We'll call them P Q R S T U.

Implementation Features supported
A P Q S T U
B P Q R T
C P Q T U
D P R S U
E P Q R S U
F P R S T
G ? ? ? ? ? ?

Seems a 'well-defined subset of C99' is still a good idea.

I'll grant you that a "well-defined subset of C99" *would be* a good
idea. Though I'd be much happier if all the relevant implementers
just implemented the whole language, eliminating the need for subsets.
Note that the latter is essentially what happened for C90; you don't
see many C compilers that fail to implement all of the C90 standard.

The problem is that nobody has actually defined such a subset -- other
than C90 itself, of course (or rather, the intersection of C90 and
C99).

Which subset this should be is hard to tell from your example: there are 4
implementations of each feature apart from P.

And in the real world, where there are more than 6 C99-specific
features and more than 6 implementations, it's nearly *impossible* to
tell what this subset should be.

I would go with the easiest to implement and/or those which already exist
anyway. It might be there is already a subset implemented across many
compilers, for example //-comments and long-long-int. That would at least be
a start, and require little effort. Eg. the subset [P] in your example.

And how would you go about enforcing this?

Let's assume, for the sake of argument, that all C compilers implement
// comments and long long. (Note that the latter also requires
library support for the *printf and *scanf functions; the library
isn't necessarily provided by the same vendor as the compiler.)

But as far as I know, no compiler enforces that particular subset.
For example, gcc also implements mixed declarations and statements.
If I'm going to write code using a well-defined subset of C99, I want
my compiler to warn me when I violate that subset. If I tell gcc to
accept // comments and long long, it will *silently* accept mixed
declarations and statements as well, and when I try to port my code to
another compiler that supports this well-defined subset, it chokes
because the other compiler *doesn't* support mixed declarations and
statements.

A conforming C90 compiler or a conforming C99 compiler will diagnose
code that fails to conform to the specified standard. That's one of
the great advantages of having a standard. If there were widely
available conforming well-defined-subset-of-C99 compilers that
diagnosed code that fails to conform to that subset, we could use that
subset with some confidence. But there aren't -- *unless* the subset
you choose is just the intersection of C90 and C99. Even then you
could miss warnings for things like implicit int that are valid C90
but invalid C99, but there are few enough features that we can live
with that.

Now if you only care about implementations that support some certain
subset of C99 features, and you're willing to accept the risk that one
compiler won't diagnose code that goes beyond that subset, and you
therefore can't be sure of how portable your code is until you test it
on all relevant systems, then that's fine; go ahead and use whatever
C99 features you like. It may even be the case that most C
programmers are in a position to do so.

And for platforms for which there is only G, and there exists a good reason
to port your code to that platform, then the customers of that platform
should demand a [P]-compliant compiler. Otherwise why should G stifle the
development and progress of all the others?

Have you ever tried *demanding* that a vendor support some particular
feature?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

jacob navia wrote, On 27/08/08 13:55:

Richard Heathfield wrote:

>Nick Keighley said:

>>On 26 Aug, 23:40, Richard Heathfield <[e-mail]:

<snip>

>>>I don't actually agree that the experiment will tell us very much that
is useful (for reasons which I can explain fully if anyone cares
enough)
go on then.

<sighI'd have thought you'd know this already. Fortunately, I've
found an easy way to explain it.

Let's just imagine a world in which Jacob Navia's test program can be
compiled on a dozen different compilers that offer "support" for C99,
with the right semantics and everything. What does that tell us about
the portability of *this* program (which, as far as I'm aware, is
legal C99, although obviously I haven't tried it because I don't have
a C99 implementation):

#include <stdio.h>
#include <math.h>
struct vector { double x; double y; };
double vector_length(const struct vector *p)
{
return sqrt(p->x * p->x + p->y * p->y);
}
int main(void)
{
printf("%f\n", vector_length(&(const struct point){.x=3.0,.y=4.0}));

Should have been:
printf("%f\n", vector_length(&(const struct vector){.x=3.0,.y=4.0}));

> return 0;
}

? And of course the answer is that it doesn't tell us anything at all.

Well, it could tell us something if you would get rid of the
errors to begin with...

PTOTBBC!!!!

(Please Turn On The Brain Before Coding)

Everyone makes mistakes occasionally. Now I've fixed it I get the
correct result from gcc here. Does it work on the other compilers you
have access to?

Also consider the following program:

#include <stdio.h>
#include <math.h>
#include <fenv.h>
#include <assert.h>

void foo(int round_dir)
{
#pragma STDC FP_CONTRACT OFF
#pragma STDC FENV_ACCESS ON
int save_round;
int setround_ok;
save_round = fegetround();
setround_ok = fesetround(round_dir);
assert(setround_ok == 0);
printf("%99.99f\n",1.0/3);
/* ... */
fesetround(save_round);
/* ... */
}

int main(void)
{
foo(FE_UPWARD);
}

I believe that if it compiles it should run without triggering the
assert and print a number slightly higher than the mathematical result
of 1/3. However gcc gives me the following:

markg@brenda:~$ gcc -std=c99 -pedantic -Wall -Wextra -lm t.c
t.c: In function ‘foo’:
t.c:8: warning: ignoring #pragma STDC FP_CONTRACT
t.c:9: warning: ignoring #pragma STDC FENV_ACCESS
markg@brenda:~$ ./a.out
0.333333333333333314829616256247390992939472198486 32812500000000000000000000000000000000000000000000 0

Note that the warnings suggest that gcc is not correctly handling the
pramas and the result is rounded down not up as requested. The function
foo is only slightly modified from an example in the standard, modified
*just* enough to give us some output to check.

Do the compilers you have access to do the right thing? Have I
miss-interpreted the standard or is gcc wrong?
--
Flash Gordon

[jacob navia]

Flash Gordon wrote:

Also consider the following program:

#include <stdio.h>
#include <math.h>
#include <fenv.h>
#include <assert.h>

void foo(int round_dir)
{
#pragma STDC FP_CONTRACT OFF
#pragma STDC FENV_ACCESS ON
int save_round;
int setround_ok;
save_round = fegetround();
setround_ok = fesetround(round_dir);
assert(setround_ok == 0);
printf("%99.99f\n",1.0/3);
/* ... */
fesetround(save_round);
/* ... */
}

int main(void)
{
foo(FE_UPWARD);
}

I believe that if it compiles it should run without triggering the
assert and print a number slightly higher than the mathematical result
of 1/3. However gcc gives me the following:

markg@brenda:~$ gcc -std=c99 -pedantic -Wall -Wextra -lm t.c
t.c: In function ‘foo’:
t.c:8: warning: ignoring #pragma STDC FP_CONTRACT
t.c:9: warning: ignoring #pragma STDC FENV_ACCESS
markg@brenda:~$ ./a.out
0.333333333333333314829616256247390992939472198486 32812500000000000000000000000000000000000000000000 0
Note that the warnings suggest that gcc is not correctly handling the
pramas and the result is rounded down not up as requested. The function
foo is only slightly modified from an example in the standard, modified
*just* enough to give us some output to check.

Do the compilers you have access to do the right thing? Have I
miss-interpreted the standard or is gcc wrong?

You have set up the rounding direction of the processor.

What is the rounding direction?

When the processor determines that the true result of a calculation
IN THE LAST BIT lies between the 1 and 0 it must ROUND the LAST BIT
either to the nearest (1 or 0) or upwards (towards + or minus inf) or
downwards (towards zero).

Note that this is done to the LAST BIT of the calculation.

Since 1/3 --0.33333333333333333333333333333333333333333333 (etc)
somewhere the processor should round to
0.3333333 (precision number of "3") 4

That result should be the one displayed by printf.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32