C return a++ - is it safe?

[James Harris]

If in C one codes a function which includes

return a++;

does 'a' get incremented? Would the behaviour be safe to rely upon? I
guess this might apply if 'a' were static or such as

return ptr->element++;

I didn't find this in the comp.lang.c faq (at least the first one that
came up from Google; there seemed to be many) but didn't find it. No
doubt someone will tell me where I should have looked.

(For the time being I'm coding: a++; return a - 1; )
--
James

[pete]

James Harris wrote:

>
If in C one codes a function which includes

return a++;

does 'a' get incremented?

Yes.

Would the behaviour be safe to rely upon?

Yes.

I guess this might apply if 'a' were static

Yes.

--
pete

[Larry__Weiss]

Richard Harter wrote:

I believe you're missing his point. Ada has a very thorough
validation suite and stringent restrictions on what may be called
an Ada compiler. This isn't the case with C compilers; anybody
can produce what they call a C compiler. It is even possible
that there is no such thing as a fully conforming C compiler.

His point is that in the real world this is the kind of thing
that you should check whether the compiler gets it right. Off
hand, I would think that it is the sort of thing that a compiler
could be expected to get right but I might well be wrong.

Do set of programs exist that attempt to validate a C implementation?

If so, are any of these freely available?

- Larry

[Chris Hills]

In article <13*************@corp.supernews.com>, Larry__Weiss
<lf*@airmail.netwrites

>Richard Harter wrote:

>I believe you're missing his point. Ada has a very thorough
validation suite and stringent restrictions on what may be called
an Ada compiler. This isn't the case with C compilers; anybody
can produce what they call a C compiler. It is even possible
that there is no such thing as a fully conforming C compiler.
His point is that in the real world this is the kind of thing
that you should check whether the compiler gets it right. Off
hand, I would think that it is the sort of thing that a compiler
could be expected to get right but I might well be wrong.

Do set of programs exist that attempt to validate a C implementation?

Yes

>If so, are any of these freely available?

No

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <47***********@mindspring.com>, pete <pf*****@mindspring.com>
writes

>James Harris wrote:

>>
If in C one codes a function which includes

return a++;

does 'a' get incremented?

Yes.

>Would the behaviour be safe to rely upon?

Yes.

>I guess this might apply if 'a' were static

Yes.

Oh dear.......

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Mark McIntyre]

On Tue, 30 Oct 2007 15:34:32 GMT, in comp.lang.c , cr*@tiac.net
(Richard Harter) wrote:

>Ada has a very thorough
validation suite and stringent restrictions on what may be called
an Ada compiler. This isn't the case with C compilers; anybody
can produce what they call a C compiler.

But this is only true to the same extent that anyone can produce
something they call an Ada compiler. For instance AFAIK its not
actually illegal in the UK or US to call your firstborn child "An Ada
Compiler".

>It is even possible
that there is no such thing as a fully conforming C compiler.

*shrug*. And possibly there are no general purpose multiplatform Ada
compilers either.

I think your point is moot since Ada and C have different uses and
scopes. Any discussion is likely to be as sensible as debating whether
fish are more useful than footballs. The answer is "it depends".

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Martin Wells]

Kenneth:

However, if "a" were a non-static non-volatile automatic variable,
can the compiler skip the increment? I believe so, because it will
go out of scope upon executing the return, and the result is "as
if" the increment were actually done.

If the local variable were neither volatile nor static, then the
increment is utterly redundant... and I wouldn't mind the compiler
issuing a warning something like:

WARNING: Redundant operation on local automatic variable

Only two reasons come to mind as to why you'd have a redundant
operation on a local automatic variable:

1) You intended to define it as either static or volatile.
2) You're stupid.

Martin

[Keith Thompson]

Chris Hills <ch***@phaedsys.orgwrites:

In article <47****************@news.sbtc.net>, Richard Harter
<cr*@tiac.netwrites

>>On Tue, 30 Oct 2007 02:03:23 -0700, Keith Thompson
<ks***@mib.orgwrote:

>>>Chris Hills <ch***@phaedsys.orgwrites:

[...]

>>>Regardless of the standard(s) I think this is one you would need to
empirically test of the compiler(s) in question.

If this were Ada one could just refer to the standard but it's C and
nothing is guaranteed.

Huh?

The C standard defines how the return statement and the "++" operator
work. If ``return a++;'' doesn't increment ``a'' (other than in cases
covered by the as-if rule), then the compiler is broken.

The C and Ada standards are both written in English, and in fairly
similar styles. C leaves more things undefined than Ada does, but
it's reasonably clear about *what* it leaves undefined.

I believe you're missing his point. Ada has a very thorough
validation suite and stringent restrictions on what may be called
an Ada compiler. This isn't the case with C compilers; anybody
can produce what they call a C compiler. It is even possible
that there is no such thing as a fully conforming C compiler.

His point is that in the real world this is the kind of thing
that you should check whether the compiler gets it right.

Precisely

>Off
hand, I would think that it is the sort of thing that a compiler
could be expected to get right but I might well be wrong.

In other words you wouldn't bet your life on it....

All software (including compilers) has bugs. All software should be
thoroughly tested. But a compiler bug in the handling of ``return
a++;'' is quite low on the list of things I'd worry about -- higher
than ``1 + 1 == 2'', lower than, say, some obscure C99 feature, and
about the same as ``return (a = 42);''.

Consider how the return statement is defined: the expression is
evaluated, and the result is returned. Updating ``a'' is part of the
evaluation of the expression.

Is there some particular reason you're concerned that a compiler might
handle something this simple incorrectly?

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

[CBFalconer]

Chris Hills wrote:

Larry__Weiss <lf*@airmail.netwrites

.... snip ...

>

>Do set of programs exist that attempt to validate a C
implementation?

Yes

>If so, are any of these freely available?

No

Yes. The gcc test suite is freely available. However it is geared
to "gcc C" rather than ISO std C.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Charlie Gordon]

"Martin Wells" <wa****@eircom.neta écrit dans le message de news:
11**********************@i13g2000prf.googlegroups. com...

Kenneth:

>However, if "a" were a non-static non-volatile automatic variable,
can the compiler skip the increment? I believe so, because it will
go out of scope upon executing the return, and the result is "as
if" the increment were actually done.

If the local variable were neither volatile nor static, then the
increment is utterly redundant... and I wouldn't mind the compiler
issuing a warning something like:

WARNING: Redundant operation on local automatic variable

Only two reasons come to mind as to why you'd have a redundant
operation on a local automatic variable:

1) You intended to define it as either static or volatile.
2) You're stupid.

Or you could be using macros with side effects:

#define GETBYTE(p) (*(p)++ & 0xFF)

int safegetbyte(const char *s) {
if (!s)
return -1;
return GETBYTE(s);
}

--
Chqrlie.

[Tor Rustad]

Chris Hills wrote:

[...]

Regardless of the standard(s) I think this is one you would need to
empirically test of the compiler(s) in question.

If this were Ada one could just refer to the standard but it's C and
nothing is guaranteed.

Well, some C compilers has been validated:

http://www.peren.com/pages/cvsa_set.htm
http://www.plumhall.com/stec.html

and at this point, the C90 test cases should detect such an compiler
bug. However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

anyway.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[James Harris]

On 30 Oct, 20:10, Keith Thompson <[e-mail]:
....

Consider how the return statement is defined: the expression is
evaluated, and the result is returned. Updating ``a'' is part of the
evaluation of the expression.

Is there some particular reason you're concerned that a compiler might
handle something this simple incorrectly?

In any context other than a return statement
mov eax, a
{use eax}
inc eax

So in a return statement
mov eax, a
ret
inc eax

which, of course, is wrong so the compiler should handle two special
cases:

1. return a++; where a is automatic
mov eax, a
ret
/* ignore the ++ */

2. return a++; where a persists
mov eax, a
mov ebx, eax
inc ebx
mov a, ebx
ret

[Dik T. Winter]

In article <ln************@nuthaus.mib.orgKeith Thompson <ks***@mib.orgwrites:
....

All software (including compilers) has bugs. All software should be
thoroughly tested. But a compiler bug in the handling of ``return
a++;'' is quite low on the list of things I'd worry about -- higher
than ``1 + 1 == 2'', lower than, say, some obscure C99 feature, and
about the same as ``return (a = 42);''.

You would be surprised at the bugs I have seen in compilers and
assemblers. It ranges from blatant errors in something akin to
include files (wrong values all over the place for floating point
attributes in the DG Ada compiler) to issuing the wrong opcode
for a particular inxtruction (a Gould assembler).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[James Kuyper]

Tor Rustad wrote:

Chris Hills wrote:

[...]

>Regardless of the standard(s) I think this is one you would need to
empirically test of the compiler(s) in question.

If this were Ada one could just refer to the standard but it's C and
nothing is guaranteed.

Well, some C compilers has been validated:

http://www.peren.com/pages/cvsa_set.htm
http://www.plumhall.com/stec.html

and at this point, the C90 test cases should detect such an compiler
bug. However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

I'm sorry - but if you have a compiler you can't trust to handle 'return
a++;' correctly, why are you using it, even for software that isn't
safety critical (and especially for code that is)? If there's any
significant likelihood that it might mishandle something that simple, I
most certainly wouldn't want to write anything more complicated in it.

[karthikbalaguru]

On Oct 31, 4:22 am, James Harris <[e-mail]>
wrote:

On 30 Oct, 20:10, Keith Thompson <[e-mail]:
...

Consider how the return statement is defined: the expression is
evaluated, and the result is returned. Updating ``a'' is part of the
evaluation of the expression.

The above answers the query :):)
So, return statement has defined that the expression is evaluated and
the
result is returned. :):)

>

Is there some particular reason you're concerned that a compiler might
handle something this simple incorrectly?

In any context other than a return statement
mov eax, a
{use eax}
inc eax

So in a return statement
mov eax, a
ret
inc eax

which, of course, is wrong so the compiler should handle two special
cases:

1. return a++; where a is automatic
mov eax, a
ret
/* ignore the ++ */

2. return a++; where a persists
mov eax, a
mov ebx, eax
inc ebx
mov a, ebx
ret

Interesting :):)

Karthik Balaguru

[Kenneth Brody]

[... Talking about "return a++;" ...]

Martin Wells wrote:

>
Kenneth:

However, if "a" were a non-static non-volatile automatic variable,
can the compiler skip the increment? I believe so, because it will
go out of scope upon executing the return, and the result is "as
if" the increment were actually done.

If the local variable were neither volatile nor static, then the
increment is utterly redundant... and I wouldn't mind the compiler
issuing a warning something like:

WARNING: Redundant operation on local automatic variable

"Redundant", or "useless"?

Only two reasons come to mind as to why you'd have a redundant
operation on a local automatic variable:

1) You intended to define it as either static or volatile.
2) You're stupid.

3) You're wondering whether your compiler will optimize it away.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Eric Sosman]

Tor Rustad wrote On 10/30/07 19:06,:

[...]
However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

What's your opinion of `return getchar();'? Keep
in mind that in many implementations, getchar() is a
macro that expands to an expression with side-effects.
On an implementation I happen to have handy at the
moment, `return getchar();' produces (reformatted for
clarity)

return ( --(( &__iob[0]))->_cnt < 0
? __filbuf( (&__iob[0]) )
: (int) *(( &__iob[0]))->_ptr++ );

So, what's your verdict? Should `return getchar();'
be avoided in safety-critical software?

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

[Dave Hansen]

On Oct 30, 11:35 am, Chris Hills <[e-mail]:

In article <[e-mail]>, Richard Harter
<[e-mail]

[...]

>

I believe you're missing his point. Ada has a very thorough
validation suite and stringent restrictions on what may be called
an Ada compiler. This isn't the case with C compilers; anybody
can produce what they call a C compiler. It is even possible
that there is no such thing as a fully conforming C compiler.

His point is that in the real world this is the kind of thing
that you should check whether the compiler gets it right.

Precisely

Off
hand, I would think that it is the sort of thing that a compiler
could be expected to get right but I might well be wrong.

In other words you wouldn't bet your life on it....

In that case (betting my life), Ada has no advantage over C.

"Trust, but verify."

Regards,

-=Dave

[Tor Rustad]

Kenneth Brody wrote:

[in addition, my response applies to Kuyper and Sosman]

Tor Rustad wrote:
[...]

>However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

anyway.

Why not? If the compiler doesn't handle it right, then I wouldn't
trust it for the rest of the "safety-critical" program either.

First, I didn't agree with Chris Hills, because

1. I didn't find such a C compiler bug likely
2. If such a compiler bug existed, the unit test should detect it

My comment on not advocating returning a++, is more of a stylish matter,
since post conditions in functions, usually follow after the last
expression, and before the return statement.

Returning expressions, obfuscate debugging too.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[Mark McIntyre]

On Wed, 31 Oct 2007 02:50:41 GMT, in comp.lang.c , James Kuyper
<ja*********@verizon.netwrote:

>Tor Rustad wrote:

>However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

I'm sorry - but if you have a compiler you can't trust to handle 'return
a++;'

AFAICS, its not a question of whether the /compiler/ can handle it,
its a question of whether the programmers understand what it does. See
for instance this entire thread.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Chris Hills]

In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

>Chris Hills wrote:

>Larry__Weiss <lf*@airmail.netwrites

... snip ...

>>

>>Do set of programs exist that attempt to validate a C
implementation?

Yes

>>If so, are any of these freely available?

No

Yes. The gcc test suite is freely available. However it is geared
to "gcc C" rather than ISO std C.

OFF TOPIC :-) this NG as you have REPEATEDLY told every one is for the
discussion of STANDARD C. GCC is not C it is "a C like language"
according to your oft repeated definition.

You of all people should refrain from this level of hypocrisy!

So it is NOT a C test suite.
It is a GCC build confirmation test.

Also AFAIK It falls far short of what a test suite for a compiler should
be.
See Perennial and Plum Hall for C test suites.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <11**********************@v3g2000hsg.googlegroups. com>, Dave
Hansen <id**@hotmail.comwrites

>On Oct 30, 11:35 am, Chris Hills <[e-mail]:

>In article <[e-mail]>, Richard Harter
<[e-mail]

[...]

>>

>I believe you're missing his point. Ada has a very thorough
validation suite and stringent restrictions on what may be called
an Ada compiler. This isn't the case with C compilers; anybody
can produce what they call a C compiler. It is even possible
that there is no such thing as a fully conforming C compiler.

>His point is that in the real world this is the kind of thing
that you should check whether the compiler gets it right.

Precisely

Off
hand, I would think that it is the sort of thing that a compiler
could be expected to get right but I might well be wrong.

In other words you wouldn't bet your life on it....

In that case (betting my life), Ada has no advantage over C.

"Trust, but verify."

Regards,

-=Dave

Absolutely,.... For years I have been arguing there is no such thing as
a
"safe" language. It is all down to the quality of the implementation
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <bJ*********************@telenor.com>, Tor Rustad
<to********@hotmail.comwrites

>Kenneth Brody wrote:

[in addition, my response applies to Kuyper and Sosman]

>Tor Rustad wrote:
[...]

>>However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

anyway.

Why not? If the compiler doesn't handle it right, then I wouldn't
trust it for the rest of the "safety-critical" program either.

First, I didn't agree with Chris Hills, because

1. I didn't find such a C compiler bug likely

"Likely" is not good enough. You have to be certain.

>2. If such a compiler bug existed, the unit test should detect it

Absolutely.

>My comment on not advocating returning a++, is more of a stylish
matter, since post conditions in functions, usually follow after the
last expression, and before the return statement.

Returning expressions, obfuscate debugging too.

I agree completely.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <1193844678.287107@news1nwk>, Eric Sosman
<Er*********@sun.comwrites

>Tor Rustad wrote On 10/30/07 19:06,:

>[...]
However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

What's your opinion of `return getchar();'? Keep
in mind that in many implementations, getchar() is a
macro that expands to an expression with side-effects.
On an implementation I happen to have handy at the
moment, `return getchar();' produces (reformatted for
clarity)

return ( --(( &__iob[0]))->_cnt < 0
? __filbuf( (&__iob[0]) )
: (int) *(( &__iob[0]))->_ptr++ );

So, what's your verdict? Should `return getchar();'
be avoided in safety-critical software?

Personally I always prefer to just return a value.

I would

a = getchar();

return a;

It also helps of you are going to single step the C (as opposed to the
assembler) or you are doing white box unit testing.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Keith Thompson]

Chris Hills <ch***@phaedsys.orgwrites:

In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

>>Chris Hills wrote:

>>Larry__Weiss <lf*@airmail.netwrites

... snip ...

>>>
Do set of programs exist that attempt to validate a C
implementation?

Yes

If so, are any of these freely available?

No

Yes. The gcc test suite is freely available. However it is geared
to "gcc C" rather than ISO std C.

OFF TOPIC :-) this NG as you have REPEATEDLY told every one is for the
discussion of STANDARD C. GCC is not C it is "a C like language"
according to your oft repeated definition.

You of all people should refrain from this level of hypocrisy!

So it is NOT a C test suite.
It is a GCC build confirmation test.

Also AFAIK It falls far short of what a test suite for a compiler
should be.
See Perennial and Plum Hall for C test suites.

I'm not familiar with the gcc test suite, but since gcc attempts to
conform to C90 and/or C95 in certain modes, I would assume that the
test suite would, among other things, test that conformance.

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

[Keith Thompson]

Chris Hills <ch***@phaedsys.orgwrites:

In article <1193844678.287107@news1nwk>, Eric Sosman
<Er*********@sun.comwrites

>>Tor Rustad wrote On 10/30/07 19:06,:

>>[...]
However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

What's your opinion of `return getchar();'? Keep
in mind that in many implementations, getchar() is a
macro that expands to an expression with side-effects.
On an implementation I happen to have handy at the
moment, `return getchar();' produces (reformatted for
clarity)

return ( --(( &__iob[0]))->_cnt < 0
? __filbuf( (&__iob[0]) )
: (int) *(( &__iob[0]))->_ptr++ );

So, what's your verdict? Should `return getchar();'
be avoided in safety-critical software?

Personally I always prefer to just return a value.

I would

a = getchar();

return a;

Ok, that's fine -- but a compiler that mishandles ``return <expr>''
would be nearly as likely to mishandle ``a = <expr>''.

I just don't see that there's any significant need to worry more about
``return a++;'' than about any other straightforward language
construct.

If you think that something like:
result = a++;
return result;
is better style than
return a++;
I won't necessarily argue -- but either form calls for exactly the
same amount of testing.

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

[Keith Thompson]

Chris Hills <ch***@phaedsys.orgwrites:

In article <bJ*********************@telenor.com>, Tor Rustad
<to********@hotmail.comwrites

>>Kenneth Brody wrote:

[in addition, my response applies to Kuyper and Sosman]

>>Tor Rustad wrote:
[...]
However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

anyway.
Why not? If the compiler doesn't handle it right, then I wouldn't
trust it for the rest of the "safety-critical" program either.

First, I didn't agree with Chris Hills, because

1. I didn't find such a C compiler bug likely

"Likely" is not good enough. You have to be certain.

What a pity that certainty is not possible.

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

[Richard Bos]

Chris Hills <ch***@phaedsys.orgwrote:

In article <bJ*********************@telenor.com>, Tor Rustad

1. I didn't find such a C compiler bug likely

"Likely" is not good enough. You have to be certain.

If you want certainty, you'll have to unplug your computer.

No, just turning it off may not be enough to be certain.

Richard

[Richard Heathfield]

Keith Thompson said:

Chris Hills writes:

>Tor Rustad writes

<snip>

>>>1. I didn't find such a C compiler bug likely

"Likely" is not good enough. You have to be certain.

What a pity that certainty is not possible.

Are you sure about that?

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

[James Kuyper]

Richard Heathfield wrote:

Keith Thompson said:

....

>What a pity that certainty is not possible.

Are you sure about that?

Reasonably sure, but not certain.

[CBFalconer]

Keith Thompson wrote:

Chris Hills <ch***@phaedsys.orgwrites:

><Er*********@sun.comwrites

.... snip ...

>>

>>On an implementation I happen to have handy at the moment,
`return getchar();' produces (reformatted for clarity)

return ( --(( &__iob[0]))->_cnt < 0
? __filbuf( (&__iob[0]) )
: (int) *(( &__iob[0]))->_ptr++ );

So, what's your verdict? Should `return getchar();'
be avoided in safety-critical software?

Personally I always prefer to just return a value.

I would
a = getchar();
return a;

Ok, that's fine -- but a compiler that mishandles ``return <expr>''
would be nearly as likely to mishandle ``a = <expr>''.

I just don't see that there's any significant need to worry more
about ``return a++;'' than about any other straightforward language
construct.

Any compiler that does any optimization should remove that 'a'
variable and simple create code for 'return getchar();'. Similarly
for 'return a++;', except that if a is local the optimizer can
eliminate the ++.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Chris Hills wrote:

Dave Hansen <id**@hotmail.comwrites

>Chris Hills <[e-mail]:

>>Richard Harter <[e-mail]

.... snip ...

>>>
Offhand, I would think that it is the sort of thing that a
compiler could be expected to get right but I might well be
wrong.

In other words you wouldn't bet your life on it....

In that case (betting my life), Ada has no advantage over C.

Absolutely,.... For years I have been arguing there is no such
thing as a "safe" language. It is all down to the quality of the
implementation

Yes, no language is 'safe'. However, some are much safer than
others. For example, the presence of subtypes (such as Pascals
ranges) simply allows range checking everywhere. Whenever a
construct creates a value for that item that is known to be out of
range, the compiler complains. When a runtime operation exceeds
that range, the runtime complains. Similarly the accurate control
of pointers allows most misuse of pointer variables to be detected
_at compile time_. This is a great advantage over C.

Unfortunately Pascal seems to have largely disappeared as a major
language. We are left with its descendent, Ada, which is a larger,
safer, and tested language. And also available in gcc.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Keith Thompson said:

>Chris Hills writes:

>>Tor Rustad writes

<snip>

>>>>1. I didn't find such a C compiler bug likely

"Likely" is not good enough. You have to be certain.

What a pity that certainty is not possible.

Are you sure about that?

Certainly (but I know I'm wrong).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kenneth Brody]

Richard Bos wrote:

>
Chris Hills <ch***@phaedsys.orgwrote:

In article <bJ*********************@telenor.com>, Tor Rustad

>1. I didn't find such a C compiler bug likely

"Likely" is not good enough. You have to be certain.

If you want certainty, you'll have to unplug your computer.

No, just turning it off may not be enough to be certain.

I have a few computers that will run for an hour or so after pulling
the plug. (At least, I think I do.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Chris Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>Chris Hills <ch***@phaedsys.orgwrites:

>In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

>>>Chris Hills wrote:
Larry__Weiss <lf*@airmail.netwrites

... snip ...

Do set of programs exist that attempt to validate a C
implementation?

Yes

If so, are any of these freely available?

No

Yes. The gcc test suite is freely available. However it is geared
to "gcc C" rather than ISO std C.

OFF TOPIC :-) this NG as you have REPEATEDLY told every one is for the
discussion of STANDARD C. GCC is not C it is "a C like language"
according to your oft repeated definition.

You of all people should refrain from this level of hypocrisy!

So it is NOT a C test suite.
It is a GCC build confirmation test.

Also AFAIK It falls far short of what a test suite for a compiler
should be.
See Perennial and Plum Hall for C test suites.

I'm not familiar with the gcc test suite, but since gcc attempts to
conform to C90 and/or C95 in certain modes, I would assume that the
test suite would, among other things, test that conformance.

The test suite will test for GCC not ISO C
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[CBFalconer]

Chris Hills wrote:

Keith Thompson <ks***@mib.orgwrites

.... snip ...

>

>I'm not familiar with the gcc test suite, but since gcc attempts
to conform to C90 and/or C95 in certain modes, I would assume
that the test suite would, among other things, test that
conformance.

The test suite will test for GCC not ISO C

Have you run it or are you just guessing? Did you find no ways to
avoid the 'gcc only' tests?

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Chris Hills <ch***@phaedsys.orgwrites:

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>>Chris Hills <ch***@phaedsys.orgwrites:

[...]

>>So it is NOT a C test suite.
It is a GCC build confirmation test.

Also AFAIK It falls far short of what a test suite for a compiler
should be.
See Perennial and Plum Hall for C test suites.

I'm not familiar with the gcc test suite, but since gcc attempts to
conform to C90 and/or C95 in certain modes, I would assume that the
test suite would, among other things, test that conformance.

The test suite will test for GCC not ISO C

If so, then it fails to test a significant part of the functionality
of gcc (i.e., gcc's ability to act as a more-or-less ISO C compiler
given certain command-line options).

Given only the phrase "gcc test suite" and what I know about gcc, I
would assume that a gcc test suite would include a number of tests for
ISO C conformance, and I would hope that those tests could be easily
separated. You appear to be asserting that this is not the case. Is
this assertion based on actual knowledge of the gcc test suite?

In any case, my assumption was a perfectly reasonable one, and Chuck
probably made the same assumption. Accusing Chuck of hypocricy for
suggesting it is needlessly insulting.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Bos]

Kenneth Brody <ke******@spamcop.netwrote:

Richard Bos wrote:

Chris Hills <ch***@phaedsys.orgwrote:

In article <bJ*********************@telenor.com>, Tor Rustad

1. I didn't find such a C compiler bug likely
>
"Likely" is not good enough. You have to be certain.

If you want certainty, you'll have to unplug your computer.

No, just turning it off may not be enough to be certain.

I have a few computers that will run for an hour or so after pulling
the plug. (At least, I think I do.)

Yeah, you never could trust those flaptops, could you?

Richard

[Chris Hills]

In article <47***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

>Chris Hills wrote:

>Keith Thompson <ks***@mib.orgwrites

... snip ...

>>

>>I'm not familiar with the gcc test suite, but since gcc attempts
to conform to C90 and/or C95 in certain modes, I would assume
that the test suite would, among other things, test that
conformance.

The test suite will test for GCC not ISO C

Have you run it or are you just guessing?

Why would run it I don't use GCC

>Did you find no ways to
avoid the 'gcc only' tests?

No.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>Chris Hills <ch***@phaedsys.orgwrites:

>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>>>Chris Hills <ch***@phaedsys.orgwrites:

[...]

>>>So it is NOT a C test suite.
It is a GCC build confirmation test.

Also AFAIK It falls far short of what a test suite for a compiler
should be.
See Perennial and Plum Hall for C test suites.

I'm not familiar with the gcc test suite, but since gcc attempts to
conform to C90 and/or C95 in certain modes, I would assume that the
test suite would, among other things, test that conformance.

The test suite will test for GCC not ISO C

>ability to act as a more-or-less ISO C compiler

I
would assume that a gcc test suite

>In any case, my assumption was a

More or less and two assumptions when discussing a test suite for
conformance to an ISO standard? No more need be said I think

When we do compiler validation there are no assumptions or more or less.

>, and Chuck
probably made the same assumption.

Another probably and assumption. When testing or validating there is no
place for probably or assumptions

Accusing Chuck of hypocricy for
suggesting it is needlessly insulting.

Chuck is VERY pedantic and insulting to other in this NG. I was judging
him by his own standards.

Also he is being VERY hypocritical GCC is Not C but "C like" as he tells
everyone else about their compiler when discussing other compilers.

He can't have it both ways.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Keith Thompson]

Chris Hills <ch***@phaedsys.orgwrites:

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>>Chris Hills <ch***@phaedsys.orgwrites:

>>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
Chris Hills <ch***@phaedsys.orgwrites:

[...]

>>>>So it is NOT a C test suite.
It is a GCC build confirmation test.
>
Also AFAIK It falls far short of what a test suite for a compiler
should be.
See Perennial and Plum Hall for C test suites.

I'm not familiar with the gcc test suite, but since gcc attempts to
conform to C90 and/or C95 in certain modes, I would assume that the
test suite would, among other things, test that conformance.

The test suite will test for GCC not ISO C

>>ability to act as a more-or-less ISO C compiler

>I
would assume that a gcc test suite

>>In any case, my assumption was a

More or less and two assumptions when discussing a test suite for
conformance to an ISO standard? No more need be said I think

When we do compiler validation there are no assumptions or more or less.

>>, and Chuck
probably made the same assumption.

Another probably and assumption. When testing or validating there is
no place for probably or assumptions

Agreed. Anybody who wants to try using the gcc test suite to test a
non-gcc ISO C compiler obviously will have to investigate the suite to
determine whether it will suits his purposes. Maybe it will, maybe it
won't.

> Accusing Chuck of hypocricy for
suggesting it is needlessly insulting.

Chuck is VERY pedantic and insulting to other in this NG. I was
judging him by his own standards.

Also he is being VERY hypocritical GCC is Not C but "C like" as he
tells everyone else about their compiler when discussing other
compilers.

He can't have it both ways.

And neither can you.

I asked you whether you're actually familiar with the gcc test suite.
Though you didn't answer directly, your responses implied that you
haven't even looked at it.

The previous poster asked about C test suites. Suggesting the gcc
test suite is perfectly reasonable (with the proviso that it *may or
may not* be suitable). You, on the other hand, are accusing Chuck of
hypocricy -- and you *don't know what you're talking about*.

Next time, do a little research before you start flinging insults.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Chris Hills <ch***@phaedsys.orgwrites:
[snip]

Also he is being VERY hypocritical GCC is Not C but "C like" as he
tells everyone else about their compiler when discussing other
compilers.

As you should know, gcc can be used as a reasonably conforming C90 or
C95 compiler, and a partially conforming C99 compiler.

But we were talking about the gcc test suite, not about gcc itself.

See <http://pcc.ludd.ltu.se/standards_and_regression_testing/and
<http://pcc.ludd.ltu.se/standards_and_regression_testing/gcc_testsuite/>
for information about using the gcc test suite on pcc, a a non-gcc C
compiler. Obviously any gcc-specific tests are expected to fail, but
it appears that the suite is still useful.

This was on the first page of Google results for "gcc test suite".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Chris Hills wrote:

Keith Thompson <ks***@mib.orgwrites

.... snip ...

>

>Accusing Chuck of hypocricy for suggesting it is needlessly
insulting.

Chuck is VERY pedantic and insulting to other in this NG. I was
judging him by his own standards.

Also he is being VERY hypocritical GCC is Not C but "C like" as
he tells everyone else about their compiler when discussing
other compilers.

Oh? Don't recall anything of the sort. I have been known to
chastise some people who insist on posting off-topic material.

BTW, "gcc -W -Wall -ansi -pedantic" is awfully close to a pure ISO
standard C compiler. That uses C95 standards, because that is what
the library on my system is compatible with, and it avoids the few
missing C99 features.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Tor Rustad]

Chris Hills wrote:

In article <bJ*********************@telenor.com>, Tor Rustad
<to********@hotmail.comwrites

>Kenneth Brody wrote:

[in addition, my response applies to Kuyper and Sosman]

>>Tor Rustad wrote:
[...]
However, in safety-critical SW, I wouldn't advocate using construct
like

return a++;

anyway.
Why not? If the compiler doesn't handle it right, then I wouldn't
trust it for the rest of the "safety-critical" program either.

First, I didn't agree with Chris Hills, because

1. I didn't find such a C compiler bug likely

"Likely" is not good enough. You have to be certain.

"Testing can show the presence of errors, but not their absence."
-E. W. Dijkstra

>2. If such a compiler bug existed, the unit test should detect it

Absolutely.

The probability of such a fault passing through, the C compiler test
cases, a C compiler validation suit and program unit test cases, is very
low. There is a range of other potential faults, I would worry far more
about.

An extremely fault tolerant system/module, could perhaps have
independent software design teams and guard against compiler faults, one
team writing the module in C, another in Ada.

Interesting, what actions should be done in case there is a mismatch in
the results. How to choose which SW module is correct? It appears, you
really need three SW teams, using 3 different languages/compilers.

Still, there is a non-zero probability, that the same compiler fault can
hit all of them, e.g. via some common mode of failure.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[Ben Bacarisse]

James Harris <ja************@googlemail.comwrites:

On 30 Oct, 20:10, Keith Thompson <[e-mail]:
...

>Consider how the return statement is defined: the expression is
evaluated, and the result is returned. Updating ``a'' is part of the
evaluation of the expression.

Is there some particular reason you're concerned that a compiler might
handle something this simple incorrectly?

In any context other than a return statement
mov eax, a
{use eax}
inc eax

Not quite "any". In a function call, f(a++) the side-effects must
have happened by the time function is entered. Of course, if the "use
it" is "push it" and the function call follows the inc (and another
mov) we are OK, but the same could also be done for the return (the
"use it" being put into register used for return values).

One has to assume a very naive understanding of values, side-effects
and sequence points to suspect the code generated from the original
line.

--
Ben.

[RoS]

In data Thu, 01 Nov 2007 09:56:28 -0500, CBFalconer scrisse:

>Chris Hills wrote:

>Dave Hansen writes

>>Chris Hills <[e-mail]:
Richard Harter <[e-mail]

... snip ...

>>>>
Offhand, I would think that it is the sort of thing that a
compiler could be expected to get right but I might well be
wrong.

In other words you wouldn't bet your life on it....

In that case (betting my life), Ada has no advantage over C.

Absolutely,.... For years I have been arguing there is no such
thing as a "safe" language. It is all down to the quality of the
implementation

Yes, no language is 'safe'. However, some are much safer than
others. For example, the presence of subtypes (such as Pascals
ranges) simply allows range checking everywhere. Whenever a
construct creates a value for that item that is known to be out of
range, the compiler complains. When a runtime operation exceeds
that range, the runtime complains. Similarly the accurate control
of pointers allows most misuse of pointer variables to be detected
_at compile time_. This is a great advantage over C.

i think i'm in your kill file so don't read what i write;

the same for very pedands ones

-----------------------------------------------------------------
------------------------------------------------------------------
you and other seems not understand the esistance of variables that
*can not* overflow e.g. size_t; or
int, unsigned, float, double etc in financial calculis etc etc

if some of that variables has an overflow it has to rappresent an
error number (eg: INT_MAX for +overflow and INT_MIN for -overflow)
so detect errors in run time is more easy

for an unsigned thype the aritimetic is very easy

0..UMAX

a+b = (a==UMAX || b==UMAX || oveflow(a+b)? UMAX : sum(a, b);
a-b = (a==UMAX || b==UMAX || a<b || oveflow(a-b)? UMAX : sum(a, b);

some like above for -*/

0..UMAX-1 is ok
UMAX is an error

>Unfortunately Pascal seems to have largely disappeared as a major
language. We are left with its descendent, Ada, which is a larger,
safer, and tested language. And also available in gcc.

>--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[santosh]

RoS wrote:

<snip>

you and other seems not understand the esistance of variables that
*can not* overflow e.g. size_t; or
int, unsigned, float, double etc in financial calculis etc etc

No. Signed types can overflow.

if some of that variables has an overflow it has to rappresent an
error number (eg: INT_MAX for +overflow and INT_MIN for -overflow)
so detect errors in run time is more easy

INT_MAX and INT_MIN are valid values. Using them to represent overflow
is, IMHO, not wise.

for an unsigned thype the aritimetic is very easy

0..UMAX

....

0..UMAX-1 is ok
UMAX is an error

No. Uxxx_MAX is a valid value of that type.

[Chris Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>Chris Hills <ch***@phaedsys.orgwrites:
[snip]

>Also he is being VERY hypocritical GCC is Not C but "C like" as he
tells everyone else about their compiler when discussing other
compilers.

As you should know, gcc can be used as a reasonably conforming C90 or
C95 compiler, and a partially conforming C99 compiler.

But we were talking about the gcc test suite, not about gcc itself.

See <http://pcc.ludd.ltu.se/standards_and_regression_testing/and
<http://pcc.ludd.ltu.se/standards_and_regression_testing/gcc_testsuite/>
for information about using the gcc test suite on pcc, a a non-gcc C
compiler. Obviously any gcc-specific tests are expected to fail, but
it appears that the suite is still useful.

This was on the first page of Google results for "gcc test suite".

CBF gets VERY pedantic about ANYTHING non standard. As far as his logic
goes for any other compiler is that it is not a C compiler but a
compiler for a C like language.

Therefore the GCC compiler and it's test suite are not for C but a C
like language.

Now you understand what pisses off almost everyone else in this NG when
a few of you shout OT for everything that is not pure ISO-C You can't
expect to have it both ways.

However for testing a non gcc compiler the GCC test suite is not really
much use. (I asked some one who does do compiler validation for the
safety critical world and who has looked at the gcc test suite)

BTW the link you gave misses out one of the main C compiler test suits.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>Chris Hills <ch***@phaedsys.orgwrites:

>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites

>>>Chris Hills <ch***@phaedsys.orgwrites:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:

More or less and two assumptions when discussing a test suite for
conformance to an ISO standard? No more need be said I think

When we do compiler validation there are no assumptions or more or less.

>>>, and Chuck
probably made the same assumption.

Another probably and assumption. When testing or validating there is
no place for probably or assumptions

Agreed. Anybody who wants to try using the gcc test suite to test a
non-gcc ISO C compiler obviously will have to investigate the suite to
determine whether it will suits his purposes. Maybe it will, maybe it
won't.

There is a lot more to validation than that. I doubt it will be of any
real use.

>> Accusing Chuck of hypocricy for
suggesting it is needlessly insulting.

Chuck is VERY pedantic and insulting to other in this NG. I was
judging him by his own standards.

Also he is being VERY hypocritical GCC is Not C but "C like" as he
tells everyone else about their compiler when discussing other
compilers.

He can't have it both ways.

And neither can you.

I agree but just for once I am having a go at CBF with his own logic. He
doesn't like it.

>I asked you whether you're actually familiar with the gcc test suite.
Though you didn't answer directly, your responses implied that you
haven't even looked at it.

Correct. I asked some one else who had.

>The previous poster asked about C test suites. Suggesting the gcc
test suite is perfectly reasonable

No it is not. The GCC test suite is for GCC not ISO-C

>(with the proviso that it *may or
may not* be suitable). You, on the other hand, are accusing Chuck of
hypocricy -- and you *don't know what you're talking about*.

He is hypocritical. Given his usual stance on anything not PURE ISO C
the Gcc test suite falls down on his own logic.

This is something I and others have complained about that a small group
of you scream OT on anything you don't like but do not apply the same
rules to yourselves.

I could have suggested any number of test suites that (according to CBF
previously) are for compilers of a "c-like" language. When these
compilers are far more ISO -c that GCC.

CBF can't have it both ways. The GCC test suite is not an ISO C test
suite it is a GCC test suite. gcc is a "C like" language. Simple as
that.

Now you see how annoying it gets to the rest of use with al this OT
crap.

When it comes to compiler validation it is one of the few areas where
you have to be very precise and CBF wants to be approximate, maybe.

Anyway the good news I I will not be bothering you for a week as I am
off on a trip. Ironically it has to do with compiler validation...
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Keith Thompson]

RoS <Ro*@not.existwrites:
[...]

i think i'm in your kill file so don't read what i write;

If you deliberately evade killfiles by changing your name, don't
complain about people reading what you write.

Better yet, stop changing your name.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"