Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   What's the deal with C99? (http://www.velocityreviews.com/forums/t601271-whats-the-deal-with-c99.html)

Bartc 03-24-2008 11:13 AM

What's the deal with C99?
 
[from 'The problems in comp.lang.c']
"Malcolm McLean" <regniztar@btinternet.com> wrote in message
news:S9qdnd_pwaEv6nranZ2dnUVZ8t-nnZ2d@bt.com...
> We're currently in the undesireable situation of having a rejected
> standard,
> C99, which means that "standard C" is no longer the precise thing it once
> was. That doesn't mean it is impossible to hold a coherent discussion. I
> don't think we can legitimately hold C99 to be off-topic, but we should
> point out that non-block top declarations are not, de facto, portable.


I've looked at the differences in C99 according to the Wikipedia C article.

It doesn't look like that much to add to C90.

So why the problem with creating compilers for it, is it motivation?

What is the most difficult part of C99 to implement?

Some of the extensions, like Complex support (I've never used complex
numbers and never will, and I'm sure many others will say the same) are
really not very interesting; perhaps that should have been optional if it
made producing the compilers easier.

Or is the real problem that there will always be C compilers that are not
C99 compatible, effectively breaking the standard because any supposedly
portable C99 code (does anyone else keep typing it as C((?) will not be
portable to those compilers?

--
Bart



jacob navia 03-24-2008 11:40 AM

Re: What's the deal with C99?
 
Bartc wrote:
> [from 'The problems in comp.lang.c']
> "Malcolm McLean" <regniztar@btinternet.com> wrote in message
> news:S9qdnd_pwaEv6nranZ2dnUVZ8t-nnZ2d@bt.com...
>> We're currently in the undesireable situation of having a rejected
>> standard,


This is wrong. gcc implements almost all of C99.
IBM xlc compiler line implements everything
Intel compilers offer some c99 support

If we apply the same standards to C++ we would say that there is no
C++ now, since no compilers implement the full C++ standard
issued 10 years ago!

>> C99, which means that "standard C" is no longer the precise thing it once
>> was.


This is not true. Standard C means the current C standard: C99

>> That doesn't mean it is impossible to hold a coherent discussion. I
>> don't think we can legitimately hold C99 to be off-topic, but we should
>> point out that non-block top declarations are not, de facto, portable.

>


Even Microsoft implements now "long long" and will improve C99 support
in the future.


> I've looked at the differences in C99 according to the Wikipedia C article.
>
> It doesn't look like that much to add to C90.
>
> So why the problem with creating compilers for it, is it motivation?
>
> What is the most difficult part of C99 to implement?
>


The problem is not C99 but the fact that C is perceived as a dead
language by GNU and Microsoft.

Every C++ book starts with a page explaining how awful C is. This
starts making believe many people that C is as awful as everybody is
saying.

The attitude of the C community (and exemplified in this group) doesn't
help at all. Obvious flaws of the language will be dismissed, any
security discussion will be rejected, etc.

It is is=nstructive to see the reaction to Microsoft's safer C proposal,
where everybody criticized Microsoft but nobody started even to
acknowledge the problems Microsoft was trying to solve.


> Some of the extensions, like Complex support (I've never used complex
> numbers and never will, and I'm sure many others will say the same) are
> really not very interesting; perhaps that should have been optional if it
> made producing the compilers easier.



lcc-win implements complex numbers using operator overloading. This way
I will be able to incoporate all kind of new number systems (decimal
number systems proposed by IBM, fixed point numbers proposed by
embedded systems people) without changing ANYTHING in the compiler.

My opinion is that this is the only true solution to this problem.

>
> Or is the real problem that there will always be C compilers that are not
> C99 compatible, effectively breaking the standard because any supposedly
> portable C99 code (does anyone else keep typing it as C((?) will not be
> portable to those compilers?
>


Most of C99 is in gcc now. The differences are minimal.


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

vippstar@gmail.com 03-24-2008 12:05 PM

Re: What's the deal with C99?
 
On Mar 24, 1:40 pm, jacob navia <ja...@nospam.com> wrote:
> Bartc wrote:
> > [from 'The problems in comp.lang.c']
> > "Malcolm McLean" <regniz...@btinternet.com> wrote in message
> >news:S9qdnd_pwaEv6nranZ2dnUVZ8t-nnZ2d@bt.com...
> >> We're currently in the undesireable situation of having a rejected
> >> standard,

>
> This is wrong. gcc implements almost all of C99.
> IBM xlc compiler line implements everything
> Intel compilers offer some c99 support

That is correct.
I've never heard before that C99 is a rejected standard.
> If we apply the same standards to C++ we would say that there is no
> C++ now, since no compilers implement the full C++ standard
> issued 10 years ago!
>
> >> C99, which means that "standard C" is no longer the precise thing it once
> >> was.

>
> This is not true. Standard C means the current C standard: C99
>
> >> That doesn't mean it is impossible to hold a coherent discussion. I
> >> don't think we can legitimately hold C99 to be off-topic, but we should
> >> point out that non-block top declarations are not, de facto, portable.

>
> Even Microsoft implements now "long long" and will improve C99 support
> in the future.

I never understood why Microsoft chose to implement __int64 but *not*
long long.
Surely, the semantics aren't the same but the MS operating systems
don't run on exotic architectures.
> > I've looked at the differences in C99 according to the Wikipedia C article.

Don't trust wikipedia, it's not a valid source.
Try C: a reference manual for the differences.

> > It doesn't look like that much to add to C90.

>
> > So why the problem with creating compilers for it, is it motivation?

Most likely yes, the features that are not implemented are rarely (if
not never) used.

> > What is the most difficult part of C99 to implement?

>
> The problem is not C99 but the fact that C is perceived as a dead
> language by GNU and Microsoft.

If it's considered dead by MS, then why lately I've seen so many
recommendations from MS in C?
As for GNU, that's not true. Sure, RMS said the language he prefers is
LISP but that's even "deader".
Moreover, RMS does not depict GNU, and most of GNU projects are in C.
You've said this multiple times, please explain what you mean by
saying that GNU considers C dead..

> Every C++ book starts with a page explaining how awful C is. This
> starts making believe many people that C is as awful as everybody is
> saying.

If you don't doubt what you read.. don't read :-).

> The attitude of the C community (and exemplified in this group) doesn't
> help at all.

I agree at this point. That's because in clc ISO C is discussed. If
you have a suggestion for the C language, there is comp.std.c
> Obvious flaws of the language will be dismissed,

No, that is not true. If there is a mistake at the standard (and there
might be) and it's pointed out only a fool would argue otherwise.
> any security discussion will be rejected, etc.

Because that is beyond the point of this group. As long as your
program is conforming you are on the safe side.

> It is is=nstructive to see the reaction to Microsoft's safer C proposal,
> where everybody criticized Microsoft but nobody started even to
> acknowledge the problems Microsoft was trying to solve.

Which problem? The proposals of MS are *pure* BS, moreover, you said
just before MS considers C to be dead.. why would MS bother then?
I don't want to see MS having any impact on the next C standard. Next
thing that happends, you'll have to pay to do anything remotely
associative with the new standard.
That does not, however, mean that I put the BS label in MS' proposals
before considering them. It's just that I've yet to see a reasonable
proposal from MS.

> > Some of the extensions, like Complex support (I've never used complex
> > numbers and never will, and I'm sure many others will say the same) are
> > really not very interesting; perhaps that should have been optional if it
> > made producing the compilers easier.

It doesn't matter whether it's optional or not. If the implementation
skips _Complex (not Complex) and documents that UB is invoked when the
programmer uses it, it's in my opinion fine. Not a conforming
implementation, but usable.

> lcc-win implements complex numbers using operator overloading. This way
> I will be able to incoporate all kind of new number systems (decimal
> number systems proposed by IBM, fixed point numbers proposed by
> embedded systems people) without changing ANYTHING in the compiler.
>
> My opinion is that this is the only true solution to this problem.
>
>
>
> > Or is the real problem that there will always be C compilers that are not
> > C99 compatible, effectively breaking the standard because any supposedly
> > portable C99 code (does anyone else keep typing it as C((?) will not be
> > portable to those compilers?

Software is not perfect. Live with it :-) (or improve it? or make your
own)

Ioannis Vranos 03-24-2008 01:12 PM

Re: What's the deal with C99?
 
jacob navia wrote:
>
> If we apply the same standards to C++ we would say that there is no
> C++ now, since no compilers implement the full C++ standard
> issued 10 years ago!



I am sorry, you are completely wrong on this. Most mainstream C++
compilers support the 100% of C++98 except of one feature, the export
template (but one compiler supports this too).

With "most mainstream C++ compilers" I mean, Visual C++, GCC, Borland
C++ products, Intel C++, and others.

Ben Bacarisse 03-24-2008 02:34 PM

Re: What's the deal with C99?
 
jacob navia <jacob@nospam.com> writes:
<snip>
> lcc-win implements complex numbers using operator overloading.


It is still an open question whether the way lcc-win32 does this can
cconform to C99. My evidence suggests that complex.h is needed to
pre-load the overloading, so compilation units that don't include
complex.h can't conform:

void f(double _Complex c);
void g(double _Complex a) { f(a * a); }

for example. Aside: is this allowed? I can't see any reason why not
but it might have made more sense for C99 to insist that feature X
requires one to include X.h. In that way, implementors could rely on
the header to trigger the mechanism. It would have allowed _Complex
to be a macro expanding to internal magic and would this have allowed
testing for complex support. Just a passing thought.

Of course, such programs are rare, and you can say you will ditch
conformance in these cases because your way is "better", but just bare
in mind that that is what the gcc people did for a while with VLAs --
and you considered that odd in another thread.

> Most of C99 is in gcc now. The differences are minimal.


It would help your case if you had a C99 conformance page like gcc
has.

--
Ben.

santosh 03-24-2008 02:53 PM

Re: What's the deal with C99?
 
vippstar@gmail.com wrote:

> On Mar 24, 1:40 pm, jacob navia <ja...@nospam.com> wrote:
>> Bartc wrote:
>> > [from 'The problems in comp.lang.c']
>> > "Malcolm McLean" <regniz...@btinternet.com> wrote in message
>> >news:S9qdnd_pwaEv6nranZ2dnUVZ8t-nnZ2d@bt.com...
>> >> We're currently in the undesireable situation of having a rejected
>> >> standard,

>>
>> This is wrong. gcc implements almost all of C99.
>> IBM xlc compiler line implements everything
>> Intel compilers offer some c99 support

> That is correct.
> I've never heard before that C99 is a rejected standard.


Well I don't about "rejected", but it's true that it has not been
received with anywhere near the enthusiasm that C90 was received.

>> If we apply the same standards to C++ we would say that there is no
>> C++ now, since no compilers implement the full C++ standard
>> issued 10 years ago!
>>
>> >> C99, which means that "standard C" is no longer the precise thing
>> >> it once was.

>>
>> This is not true. Standard C means the current C standard: C99
>>
>> >> That doesn't mean it is impossible to hold a coherent discussion.
>> >> I don't think we can legitimately hold C99 to be off-topic, but we
>> >> should point out that non-block top declarations are not, de
>> >> facto, portable.

>>
>> Even Microsoft implements now "long long" and will improve C99
>> support in the future.

> I never understood why Microsoft chose to implement __int64 but *not*
> long long.
> Surely, the semantics aren't the same but the MS operating systems
> don't run on exotic architectures.


Anyway the workaround is trivial. The problem is that MS does not
implement a *lot* of C99. If it was *only* long long, there would be
little complaint.

>> > I've looked at the differences in C99 according to the Wikipedia C
>> > article.

> Don't trust wikipedia, it's not a valid source.
> Try C: a reference manual for the differences.
>
>> > It doesn't look like that much to add to C90.

>>
>> > So why the problem with creating compilers for it, is it
>> > motivation?

> Most likely yes, the features that are not implemented are rarely (if
> not never) used.
>
>> > What is the most difficult part of C99 to implement?

>>
>> The problem is not C99 but the fact that C is perceived as a dead
>> language by GNU and Microsoft.

> If it's considered dead by MS, then why lately I've seen so many
> recommendations from MS in C?


Where? I haven't seen anything. Have you any links?

> As for GNU, that's not true. Sure, RMS said the language he prefers is
> LISP but that's even "deader".
> Moreover, RMS does not depict GNU, and most of GNU projects are in C.
> You've said this multiple times, please explain what you mean by
> saying that GNU considers C dead..


Jacob, I believe, is saying that the *gcc* developers have shifted most
of their efforts to g++ and not gcc. To an extent this is probably
true, but it's true for all mainstream compilers. They have *all* shown
more interest in C++ than with C, and C99 in particular. It's only "C
only" compilers like Jacob's and PellesC that have, by needs, focused
on C99 exclusively.

>> Every C++ book starts with a page explaining how awful C is. This
>> starts making believe many people that C is as awful as everybody is
>> saying.

> If you don't doubt what you read.. don't read :-).
>
>> The attitude of the C community (and exemplified in this group)
>> doesn't help at all.

> I agree at this point. That's because in clc ISO C is discussed. If
> you have a suggestion for the C language, there is comp.std.c
>> Obvious flaws of the language will be dismissed,

> No, that is not true. If there is a mistake at the standard (and there
> might be) and it's pointed out only a fool would argue otherwise.


You are not getting what he is saying. He is not talking about errors in
ISO 9899:1999, but about "language flaws", i.e., things like null
terminated strings and their functions in string.h, *alloc/free instead
of GC, lack of operator overloading etc. *He* perceives these as flaws
in the language.

>> any security discussion will be rejected, etc.

> Because that is beyond the point of this group. As long as your
> program is conforming you are on the safe side.


He is saying that the *wider* C programming community more often than
not rejects proposals for adding things like GC, counted strings,
operator overloading etc., which *he* sees as a negative response and a
failure to keep up with the state of the art.

>> It is is=nstructive to see the reaction to Microsoft's safer C
>> proposal, where everybody criticized Microsoft but nobody started
>> even to acknowledge the problems Microsoft was trying to solve.

> Which problem? The proposals of MS are *pure* BS, moreover, you said
> just before MS considers C to be dead.. why would MS bother then?
> I don't want to see MS having any impact on the next C standard. Next
> thing that happends, you'll have to pay to do anything remotely
> associative with the new standard.
> That does not, however, mean that I put the BS label in MS' proposals
> before considering them. It's just that I've yet to see a reasonable
> proposal from MS.


I agree here. The "safe C" proposal by MS is next to useless, and if
standardised, will only add more bloat to the language and help to
further sunder implementations.

>> > Some of the extensions, like Complex support (I've never used
>> > complex numbers and never will, and I'm sure many others will say
>> > the same) are really not very interesting; perhaps that should have
>> > been optional if it made producing the compilers easier.

> It doesn't matter whether it's optional or not. If the implementation
> skips _Complex (not Complex) and documents that UB is invoked when the
> programmer uses it, it's in my opinion fine. Not a conforming
> implementation, but usable.


Things like complex support are seldom used outside specialised areas.
So they *could* have been optional like IEC 60559 support. This would
probably have motivated many implementors to make more efforts towards
conformance.

<snip>


santosh 03-24-2008 03:53 PM

Re: What's the deal with C99?
 
Ben Bacarisse wrote:

> jacob navia <jacob@nospam.com> writes:
> <snip>
>> lcc-win implements complex numbers using operator overloading.

>
> It is still an open question whether the way lcc-win32 does this can
> cconform to C99. My evidence suggests that complex.h is needed to
> pre-load the overloading, so compilation units that don't include
> complex.h can't conform:
>
> void f(double _Complex c);
> void g(double _Complex a) { f(a * a); }
>
> for example. Aside: is this allowed? I can't see any reason why not
> but it might have made more sense for C99 to insist that feature X
> requires one to include X.h. In that way, implementors could rely on
> the header to trigger the mechanism.


Couldn't Jacob still include complex.h behind the scenes when he
encounters _Complex?

[ ... ]

>> Most of C99 is in gcc now. The differences are minimal.

>
> It would help your case if you had a C99 conformance page like gcc
> has.


In the case of gcc's page, it's rather disappointing that while it
mentions which feature is implemented and which is not, no rationale is
given for failure to implement (well apart from a few footnotes)
feature X. That would at least give us an idea of *why* gcc has not
implemented certain C99 facilities, and the prognosis for their future
inclusion.


Harald van Dijk 03-24-2008 04:09 PM

Re: What's the deal with C99?
 
On Mon, 24 Mar 2008 21:23:59 +0530, santosh wrote:
> Ben Bacarisse wrote:
>> jacob navia <jacob@nospam.com> writes: <snip>
>>> lcc-win implements complex numbers using operator overloading.

>>
>> It is still an open question whether the way lcc-win32 does this can
>> cconform to C99. My evidence suggests that complex.h is needed to
>> pre-load the overloading, so compilation units that don't include
>> complex.h can't conform:
>>
>> void f(double _Complex c);
>> void g(double _Complex a) { f(a * a); }
>>
>> for example. Aside: is this allowed? I can't see any reason why not
>> but it might have made more sense for C99 to insist that feature X
>> requires one to include X.h. In that way, implementors could rely on
>> the header to trigger the mechanism.

>
> Couldn't Jacob still include complex.h behind the scenes when he
> encounters _Complex?


No, when complex numbers get used, it is wrong to automatically include
the macros and functions that <complex.h> provides. The names are not
reserved for the implementation; the user is free to use them for other
purposes.

It would be perfectly valid to automatically include some other header,
as long as this only defines the operators, and no more. Some other
compilers automatically include <startup.h> or similar which can be
easily extended, and I expect this approach would work very well on lcc
too.

santosh 03-24-2008 04:24 PM

Re: What's the deal with C99?
 
Harald van D?k wrote:

> On Mon, 24 Mar 2008 21:23:59 +0530, santosh wrote:
>> Ben Bacarisse wrote:
>>> jacob navia <jacob@nospam.com> writes: <snip>
>>>> lcc-win implements complex numbers using operator overloading.
>>>
>>> It is still an open question whether the way lcc-win32 does this can
>>> cconform to C99. My evidence suggests that complex.h is needed to
>>> pre-load the overloading, so compilation units that don't include
>>> complex.h can't conform:
>>>
>>> void f(double _Complex c);
>>> void g(double _Complex a) { f(a * a); }
>>>
>>> for example. Aside: is this allowed? I can't see any reason why
>>> not but it might have made more sense for C99 to insist that feature
>>> X
>>> requires one to include X.h. In that way, implementors could rely
>>> on the header to trigger the mechanism.

>>
>> Couldn't Jacob still include complex.h behind the scenes when he
>> encounters _Complex?

>
> No, when complex numbers get used, it is wrong to automatically
> include the macros and functions that <complex.h> provides. The names
> are not reserved for the implementation; the user is free to use them
> for other purposes.
>
> It would be perfectly valid to automatically include some other
> header, as long as this only defines the operators, and no more. Some
> other compilers automatically include <startup.h> or similar which can
> be easily extended, and I expect this approach would work very well on
> lcc too.


Yes. I should have been more precise in what I said. I meant that
lcc-win would include only those portions of complex.h which are needed
for compiling code involving _Complex, unless of course complex.h was
explicitly included by the programmer.

But as you say, this might be better placed in a private header or even
within the compiler.


jacob navia 03-24-2008 04:30 PM

Re: What's the deal with C99?
 
santosh wrote:
>
> Yes. I should have been more precise in what I said. I meant that
> lcc-win would include only those portions of complex.h which are needed
> for compiling code involving _Complex, unless of course complex.h was
> explicitly included by the programmer.
>
> But as you say, this might be better placed in a private header or even
> within the compiler.
>


Yes, that's a good idea.

I think that in the lexer, the first time I see
_Complex
I will include <complexoperators.h>

The standard file
<complex.h>
will include
<complexoperators.h> but define more things like
I
and other stuff.


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


All times are GMT. The time now is 12:27 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.