please comment

[Sheldon Simms]

Dan Pop's point, I think, is that the C99 standard is not yet widely
implemented, and code that depends on it is therefore non-portable and
not suitable for discussion in this newsgroup.

So that would mean that ISO Standard C is off topic in comp.lang.c.
That is an interesting point of view.

 

[Keith Thompson]

So that would mean that ISO Standard C is off topic in comp.lang.c.
That is an interesting point of view.

It's entirely possible that I've overstated his position; please don't
judge his words by my interpretation of them.

 

[Dan Pop]

Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).

Nope, still works:

[sheldon@wsxyz mcc]$ cat test.c
#include <math.h>
#include <stdio.h>

int main (void)
{
printf("%g\n", HUGE_VALF);
return 0;
}
[sheldon@wsxyz mcc]$ gcc -Wall -W -O2 -std=c99 -pedantic test.c

To what C standard does gcc conform when using the -std=c99 option?

Dan

 

[Dan Pop]

Our resident idiot strikes again. It's not a matter of accepting
nonstandard macros, it's a matter of defining them in the standard
headers.

More importantly, HUGE_VALF *is* actually a standard macro, so when
I compile with the flag "-std=c99" and it works, this is only to
be expected.

As an aside, if I compile with "-std=c89", HUGE_VALF is not recognized
as a valid macro, and if I compile with "-traditional" then the keyword
'const' isn't recognized. But since C99 is the current standard, these
bits of trivia are uninteresting, IMO.

C99 may be the current standard, but the conforming C99 are few and
far between. And gcc is NOT a conforming C99 compiler, no matter how
you invoke it.

Dan

 

[Dan Pop]

It's entirely possible that I've overstated his position; please don't
judge his words by my interpretation of them.

My position is that C89 hosted implementations are the *default* for this
newsgroup, and hence C89/C90 is the *default* standard for this newsgroup.
The reasons should be obvious. When someone wants to talk about C99,
this should be explicitly mentioned, just as in the case of K&R C or
freestanding implementations.

Therefore, it is *unacceptable* to post C99 solutions without *explicitly*
qualifying them as such. There is no point in confusing the people who
are not intimately familiar with the various C standards.

Dan

 

[Sheldon Simms]

On Sun, 09 Nov 2003 17:34:44 -0800, Peter Nilsson wrote:

...
amanayin wrote:

float div(float a, float b)
{
float c;

The function will return more predictable results if you
#include <math.h> and then initialize c:

float c = INFINITY;

ICBW, but I don't think INFINITY was required for <math.h> in C90.

That may be true but the current standard is C99.

Personally I don't know if either of the two macros are required
in C90. I know that both are required in C99 and that HUGE_VALF
actually appears in <math.h> on my system (with the value 'Inf').

Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).

Nope, still works:

[sheldon@wsxyz mcc]$ cat test.c
#include <math.h>
#include <stdio.h>

int main (void)
{
printf("%g\n", HUGE_VALF);
return 0;
}
[sheldon@wsxyz mcc]$ gcc -Wall -W -O2 -std=c99 -pedantic test.c

To what C standard does gcc conform when using the -std=c99 option?

None. However it is being invoked with an option to "determine the
language standard". Whether it actually conforms to C99 is beside the
point anyway. Would it make any difference if I bought a C99 compiler?

 

[Sheldon Simms]

On Tue, 11 Nov 2003 04:09:25 +0000, Keith Thompson wrote: [...]
Dan Pop's point, I think, is that the C99 standard is not yet widely
implemented, and code that depends on it is therefore non-portable and
not suitable for discussion in this newsgroup.

So that would mean that ISO Standard C is off topic in comp.lang.c.
That is an interesting point of view.

It's entirely possible that I've overstated his position; please don't
judge his words by my interpretation of them.

My position is that C89 hosted implementations are the *default* for this
newsgroup, and hence C89/C90 is the *default* standard for this newsgroup.
The reasons should be obvious. When someone wants to talk about C99,
this should be explicitly mentioned, just as in the case of K&R C or
freestanding implementations.

Therefore, it is *unacceptable* to post C99 solutions without *explicitly*
qualifying them as such. There is no point in confusing the people who
are not intimately familiar with the various C standards.

Thanks for your opinion, Mr. President of comp.lang.c. I respectfully
disagree that the current ISO standard for C is a second class standard in
this group.

 

[Dan Pop]

[sheldon@wsxyz mcc]$ gcc -Wall -W -O2 -std=c99 -pedantic test.c

To what C standard does gcc conform when using the -std=c99 option?

None.

So, you have to invoke gcc in non-conforming mode to get the desired
behaviour. Precisely my point!

However it is being invoked with an option to "determine the
language standard". Whether it actually conforms to C99 is beside the
point anyway.

It is entirely the point!

Would it make any difference if I bought a C99 compiler?

It would make a difference if the usual C implementations used by the
average C programmer had a C99-conforming mode. Until then, C99 is
the default in comp.std.c and C89/C90 in comp.lang.c. Regardless of
your personal opinions.

This newsgroup is supposed to actually help people and giving them
advice that require "exotic" implementations without mentioning it
explicitly is far from being helpful. Then again, you may have a
different agenda than the rest of us...

Dan

 

[Mark McIntyre]

(I wrote)

Dan Pop's point, I think, is that the C99 standard is not yet widely
implemented, and code that depends on it is therefore non-portable and
not suitable for discussion in this newsgroup.

If that was Dan's point, he misexpressed it. His quoted comment above
reads to me as "if your compiler still has a definition of HUGE_VALF
when in conforming mode, then its broken". AFAIK this is not strictly
true - a compiler could have any number of private definitions in
scope even in the most conforming mode it has.

It's true that HUGE_VALF is required in C99; it may also be provided
(in a non-conforming mode) by some C90 implementations that have added
partial C99 support.

It's also true that a strict C90 compiler, invoked in conforming mode,
is not allowed to declare a HUGE_VALF macro in <math.h>.

In /strictly/ conforming mode, perhaps, if by strictly conforming you
mean a mode which implements only that which is defined in the
standard and no more.

However we've frequently discussed the utility and even the existence
of strictly conforming mode before, and I believe Dan has been a
strong advocate of its uselessness and irrelevance. My own opinion is
that no such mode exists - the standard is prescriptive not
proscriptive for the most part.

 

[Sheldon Simms]

This newsgroup is supposed to actually help people and giving them
advice that require "exotic" implementations without mentioning it
explicitly is far from being helpful.

I am sorry. I abase myself. I will never again suggest the use of a
Standard C feature that happens to be implemented in an "exotic"
implementation such as GCC.

Then again, you may have a different agenda than the rest of us...

Yes, my agenda has been to confuse people by encouraging the use of
standard C features, even though they are not available in non-"exotic"
implementations. How did you know?

 

[Keith Thompson]

On Tue, 11 Nov 2003 04:09:25 GMT, in comp.lang.c , Keith Thompson


In /strictly/ conforming mode, perhaps, if by strictly conforming you
mean a mode which implements only that which is defined in the
standard and no more.

However we've frequently discussed the utility and even the existence
of strictly conforming mode before, and I believe Dan has been a
strong advocate of its uselessness and irrelevance. My own opinion is
that no such mode exists - the standard is prescriptive not
proscriptive for the most part.

There's an excellent reason *not* to declare user-space identifiers as
macros in standard headers. If any identifier I want to use in my
program might be declared as a macro, how can I write reasonably
portable code?

I used a strictly conforming program as my example to emphasize the
point. More generally, the point is that if an identifier FOO is not
reserved, I should be able to use it in my code.

BTW, I don't think there's such a thing as "strictly conforming mode";
the term "strictly conforming" applies to programs, not to
implementations.

 

[Mark McIntyre]

I used a strictly conforming program as my example to emphasize the
point.

But /was/ it strictly conforming? I'm just asking.

More generally, the point is that if an identifier FOO is not
reserved, I should be able to use it in my code.

I guess my point was that C89 didn't reserve identifiers beginning
with capital H for future library direction did it?

BTW, I don't think there's such a thing as "strictly conforming mode";
the term "strictly conforming" applies to programs, not to
implementations.

Absolutely. Which is partly why I reckon its meaningless to claim that
an implementation is "broken" if in "conforming mode" it doesn't or
indeed does do something or other. A

 

[Keith Thompson]

But /was/ it strictly conforming? I'm just asking.

I believe so. It was certainly intended to be.

Here's the program I posted:

#include <math.h>
int main (void)
{
int HUGE_VALF;
return 0;
}

I believe this is a strictly conforming C90 program, but not a

I guess my point was that C89 didn't reserve identifiers beginning
with capital H for future library direction did it?

No, it didn't, and yes, there are things in C99 that break strictly
conforming C90 programs. I think many things in C99 were compromises
between strict upward compatibility and esthetics. The _Bool keyword
avoids intruding on the user's name space, but surely if it had been
added to C in the beginning it would have been spelled bool.

In the case of HUGE_VALF (and HUGE_VALL), I think the committee
decided that making it look consistent with the existing HUGE_VAL was
more important than strict compatibility. Probably few, if any,
existing programs used HUGE_VALF as an identifier (unlike the fairly
common use of "bool"), and such uses are fairly easy to identify.

Absolutely. Which is partly why I reckon its meaningless to claim that
an implementation is "broken" if in "conforming mode" it doesn't or
indeed does do something or other.

I don't follow your reasoning. If a C90 implementation (in
"conforming mode") doesn't properly handle a strictly conforming
program, it's broken, and it's likely to mishandle a lot of real-life
programs as well. If we don't require at least that much conformance
among C implementations, we might as well not have a standard. On the
other hand, if a C90 implementation's only non-conformities are
attempts to implement C99 features, like adding HUGE_VALF to <math.h>,
I'm inclined to cut it a little slack. On the other other hand,
unless it implements all of C99, it should probably have a way to turn
off the C99 features.

There are some incompatible changes introduced by new standards, but
that only happens once a decade or so, and it's usually not too
difficult to work around the changes. If I were an absolute purist,
I'd insist on _HUGE_VALF, _Restricte, _Inline, and so forth, and all
valid C90 programs would be valid C99 programs with the same
semantics. But I'm not.

 

[Dan Pop]

I believe so. It was certainly intended to be.

Here's the program I posted:

#include <math.h>
int main (void)
{
int HUGE_VALF;
return 0;
}

I believe this is a strictly conforming C90 program, but not a
strictly conforming C99 program (because C99's <math.h> declares
HUGE_VALF as a macro).

Warning: you're arguing with the comp.lang.c's resident idiot.
Mark McIntyre is immune to any kind of rational argument and he has
proven it many times.

Feel free to waste your time, but you have been warned...

Dan

 

[Mark McIntyre]

I believe so. It was certainly intended to be.

<nitpick level=99>
Hmm. "strictly conforming". According to the standard, it shall use
only those features of the language and library specified in the
Standard.
I could therefore claim that since HUGE_VALF is not specified in the
Standard, its not a strictly conforming program.

I don't follow your reasoning. If a C90 implementation (in
"conforming mode") doesn't properly handle a strictly conforming
program, it's broken.

Err.....
But if, as you yourself say in the retained quote above, there's no
such thing as strictly conforming mode, then how can it be in it?

 

[Thomas Stegen]

<nitpick level=99>
Hmm. "strictly conforming". According to the standard, it shall use
only those features of the language and library specified in the
Standard.
I could therefore claim that since HUGE_VALF is not specified in the
Standard, its not a strictly conforming program.

So you are saying that it is impossible to write a strictly
conforming program.

The program, which you snipped, was strictly conforming to C90. Just
to make that clear (and it was clear).

Err.....
But if, as you yourself say in the retained quote above, there's no
such thing as strictly conforming mode, then how can it be in it?

Because the standard defines what a strictly conforming program is...
Maybe you should read the paragraph again, there is never any mention
of strictly conforming mode.

 

[Keith Thompson]

<nitpick level=99>
Hmm. "strictly conforming". According to the standard, it shall use
only those features of the language and library specified in the
Standard.
I could therefore claim that since HUGE_VALF is not specified in the
Standard, its not a strictly conforming program.
</nitpick>

Huh? The program I posted doesn't use HUGE_VALF, the macro declared
in C99's <math.h>; it simply uses HUGE_VALF as an identifier. As I
already said, it's a strictly conforming C90 program, but not a
strictly conforming C99 program.

Err.....
But if, as you yourself say in the retained quote above, there's no
such thing as strictly conforming mode, then how can it be in it?

I never used the phrase "strictly conforming mode", just "conforming
mode".

The term "conforming mode" (referring to an implementation) doesn't
actually appear in the standard, but it's common for an actual
implementation to provide some kind of mode (e.g., a set of
command-line options) intended to cause it to be a conforming
implementation. The phrase I used,
a C90 implementation (in "conforming mode")
is what the standard calls simply a "conforming implementation".

The C90 vs. C99 stuff is really a side issue. The point is that a
conforming implementation cannot declare, in a standard header, any
identifier not specified in the standard or reserved for the
implementation if it will interfere with a program's use of that
identifier. An implementation that declares FOO as a macro in
<math.h> is probably not conforming, because it can interfere with a
valid program that uses FOO as an identifier.