C99 portability challenge

[Bartc]

Re: C99 portability challenge


"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:L86dnT2o1O kGxijVRVnyiwA@b t.com...

Bartc said:
>

>>
>"Richard Heathfield" <rjh@see.sig.in validwrote in message
>news:bfCdner22 9ub3ijVnZ2dnUVZ 8gidnZ2d@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]

Re: C99 portability challenge

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]

Re: C99 portability challenge

"Bartc" <bc@freeuk.comw rites:

"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:L86dnT2o1O kGxijVRVnyiwA@b t.com...

[...]

>It depends on your goals. If you don't know in advance on which
>implementation s 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.
>>
>Implementati on 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_Keit h) kst-u@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]

Re: C99 portability challenge

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

Richard Heathfield wrote:

>Nick Keighley said:
>>

>>On 26 Aug, 23:40, Richard Heathfield <r...@see.sig.i nvalidwrote:

>>
><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(c onst 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(roun d_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.3333333333333 333148296162562 473909929394721 984863281250000 000000000000000 000000000000000 00000000000

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]

Re: C99 portability challenge

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(roun d_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.3333333333333 333148296162562 473909929394721 984863281250000 000000000000000 000000000000000 00000000000
>
>
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.3333333333333 333333333333333 333333333333333 3 (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

[Keith Thompson]

Re: C99 portability challenge

vippstar@gmail. com writes:

On Aug 27, 12:53 pm, jacob navia <ja...@nospam.c omwrote:

>vipps...@gmail .com wrote:

On Aug 27, 6:19 am, Anand Hariharan <mailto.anand.h ariha...@gmail. com>
wrote:
>On Aug 26, 3:07 am, jacob navia <ja...@nospam.c omwrote:

>>

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

They're very similar, and they have the same subject header. jacob
should at least have mentioned in each that he was posting a very
similar article to the other newsgroup.

I don't necessarily agree that it was off-topic for csc. The question
of whether C99 is sufficiently widely implemented is relevant to the
maintenance of the current standard and the development of the next
one. (Whether jacob's article actually says anything about that is
another question, but that was the intent.)

--
Keith Thompson (The_Other_Keit h) kst-u@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]

Re: C99 portability challenge

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

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(roun d_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.333333333333 333314829616256 247390992939472 198486328125000 000000000000000 000000000000000 000000000000
>>
>>
>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.3333333333333 333333333333333 333333333333333 3 (etc)
somewhere the processor should round to
0.3333333 (precision number of "3") 4
>
That result should be the one displayed by printf.

OK, I can accept that the result could possibly be correct. However, if
I change FE_UPWARD to FE_DOWNWARD I get the same result. I really find
it hard to believe that the correct result for upward and downward
rounding is the same when the number cannot be accurately represented.

Also if I change 1.0/3 to 1.0/10 I get, whatever rounding I select, a
result of:
0.1000000000000 000055511151231 257827021181583 404541015625000 000000000000000 000000000000000 00000000000

Again, I find it *incredibly* hard to believe that this is the correct
result for both upward and downward rounding.

Also you have not said whether the other compilers you have access to
(including your own) do the correct thing (whatever that is) with this
code. It is not complex and to some people for whom C99 could be of
interest the correct operation of things like this is important.

Finally you have not addressed the point that if gcc is ignoring the
pragmas I am using (as it claims) then there is something that it is
doing wrong.
--
Flash Gordon

[jacob navia]

Re: C99 portability challenge

See the thread "Another C99 challenge" for my answer.

[Bill Reid]

Re: C99 portability challenge


Nick Keighley <nick_keighley_ nospam@hotmail. comwrote in message
news:d93ff3fd-e827-41a7-8c92-daf9d6e9fbc3@k7 g2000hsd.google groups.com...

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

Yes, clueless Google(TM) Groups user, yes it does.

As one example, apparently C99 adds a "hh" input specifier
modifier to *scanf(). The other day I got curious about this, so
although my compiler does not include this in the documentation,
and generally it SEEMS to mean C89 when it refers to "ANSI
Standard C", it does have several C99-"like" "extensions " (some
of which are actually documented, others not), I tried assigning
a small integer to an unsigned char using "%hhu".

It worked! So I tried changing an entire library that uses HUNDREDS
of *scanf()s, did a fairly quick global, ran them through the library
test suite, and found they ALL WORKED!!!

EXCEPT ONE!!! One lousy *scanf() returned 0 trying to scan like
"19" or something!!! Out of SEVERAL HUNDRED conversions, ONE
DIDN'T WORK RIGHT!!!

So is that a bug in my compiler? Remember, they don't document
the "hh" modifier AT ALL, so I can't very well complain can I? How
portable is that, I mean, it's not even RELIABLY portable to my OWN
"implementation "...

Just for the record, VLAs are supported and documented as a
"special extension" to the "ANSI C Standard", as are "//" comments
(it's a C/C++ compiler anyway) and some other stuff like that (again,
some documented, some not), but NOT mixing declarations...

---
William Ernest Reid

[new to c]

Re: C99 portability challenge

Ben Bacarisse wrote:

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

Why lcc-win32 is sometimes on-topic and is sometimes off-topic here?

I ask question about C and lcc-win32 and Keith Thompson and Santosh say I troll.

You ask question about lcc-win32 and people not say you troll.

Why is difference?

[Ben Bacarisse]

Re: C99 portability challenge

new to c <non@spam.inval idwrites:

Ben Bacarisse wrote:
>

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

>
Why lcc-win32 is sometimes on-topic and is sometimes off-topic here?
>
I ask question about C and lcc-win32 and Keith Thompson and Santosh
say I troll.
>
You ask question about lcc-win32 and people not say you troll.
>
Why is difference?

If there is a difference, it is probably that I was replying to a
message that was already either on- or off-topic depending on your
view.

Personally, I think questions about, and discussion of, compiler
conformance are on topic here, but other may well disagree. No doubt
they will tell me so.

--
Ben.

[Richard Heathfield]

Re: C99 portability challenge

Ben Bacarisse said:

new to c <non@spam.inval idwrites:
>

>Ben Bacarisse wrote:
>>

>>>
>>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
>>initialiser s, compound literals, VLAs, variable macro argument lists
>>and non-constant initialisations make it too fragile.

>>
>Why lcc-win32 is sometimes on-topic and is sometimes off-topic here?
>>
>I ask question about C and lcc-win32 and Keith Thompson and Santosh
>say I troll.
>>
>You ask question about lcc-win32 and people not say you troll.
>>
>Why is difference?

>
If there is a difference, it is probably that I was replying to a
message that was already either on- or off-topic depending on your
view.
>
Personally, I think questions about, and discussion of, compiler
conformance are on topic here, but other may well disagree. No doubt
they will tell me so.

It is perfectly reasonable and topical to ask a question to the effect that
"my compiler exhibits such-and-such a behaviour for such-and-such code. Is
this consistent with the behaviour of a conforming compiler?" Whether or
not the compiler is actually named, the question is clearly topical since
it is really a question about the C language.

Keith's question is an upside-down version of this. It's asking "given a
correct C program, does a particular, named compiler exhibit conforming
behaviour?" Whether this is a topical question is not clear, and in such
cases it makes sense to extend the benefit of the doubt.

I'm a little puzzled by "new to c"'s question, since I can only find one
question of his about lcc-win32 in the "Google Groups" archives. In fact,
I only found one post at all by "new to c" in those archives (I guess his
latest article hasn't hit their server yet as I write this.) It asked two
questions, one of which was about portability and one of which was about
the -A -A flag combination in lcc-win32, and I don't see any sign of
either question being criticised as being off-topic.

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

[Ian Collins]

Re: C99 portability challenge

new to c wrote:

Ben Bacarisse wrote:
>

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

>
Why lcc-win32 is sometimes on-topic and is sometimes off-topic here?
>

It's on topic if it's being bashed.
It's off topic if it's being advertised.

:)

--
Ian Collins.

[Ben Bacarisse]

Re: C99 portability challenge

Richard Heathfield <rjh@see.sig.in validwrites:

Ben Bacarisse said:
>

>new to c <non@spam.inval idwrites:

<snip>

>>I ask question about C and lcc-win32 and Keith Thompson and Santosh
>>say I troll.
>>>
>>You ask question about lcc-win32 and people not say you troll.
>>>
>>Why is difference?

>>
>If there is a difference, it is probably that I was replying to a
>message that was already either on- or off-topic depending on your
>view.
>>

<snip>

I'm a little puzzled by "new to c"'s question, since I can only find one
question of his about lcc-win32 in the "Google Groups" archives.

I think "new to c" may post under various names, but I don't really
know. There were a few seemingly similar questions a while back that
caused the last such poster -- "new to c" -- to be accused of trying
to stir things up.

In fact,
I only found one post at all by "new to c" in those archives (I guess his
latest article hasn't hit their server yet as I write this.) It asked two
questions, one of which was about portability and one of which was about
the -A -A flag combination in lcc-win32, and I don't see any sign of
either question being criticised as being off-topic.

He/she said (s)he was accused of being a troll and that is exactly what
happened.

If I am brutally honest, I suspect my posting about lcc-win32's
conformance to C99 was essentially unhelpful. It may have been
prompted by exasperation at Jacob Navia promoting the use of a
language standard that his compiler has only limited support for but,
as such, it was as much a "troll" as many posts here since it was
short on information (what works and what does not) and high on
rhetoric (irony is a favourite rhetorical device).

--
Ben.

[Richard Heathfield]

Re: C99 portability challenge

Ian Collins said:

new to c wrote:

<snip>

>Why lcc-win32 is sometimes on-topic and is sometimes off-topic here?
>>

It's on topic if it's being bashed.
It's off topic if it's being advertised.

Smiley noted, but such a joke may well be taken too seriously by the
humourless, so I'm going to puncture it. (Sorry.)

Specific compilers are off-topic whether they are being advertised or
bashed. Nevertheless, there are times when it does make sense to discuss
how different compilers deal with various issues (e.g.
implementation-defined behaviour), and concrete examples can be useful in
that context.

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