C99 Versus ANSI.

[Richard Heathfield]

Jean-Marc Bourguet said:

The library seems to be there. Do you want I check anything in detail?

No, thanks. I'm not overly fussed about C99, as you probably realise. I
write my code to be valid in both C90 and C99, so when C99 becomes *widely*
implemented I'll be ready to start using its new features - if I live that
long.

 

[Jean-Marc Bourguet]

Jean-Marc Bourguet said:


No, thanks. I'm not overly fussed about C99, as you probably realise. I
write my code to be valid in both C90 and C99, so when C99 becomes *widely*
implemented I'll be ready to start using its new features - if I live that
long.

I've quite another approach: when one feature is usefull, I check to see if
it is supported on all the target platforms and if it is, I use it. There
is no need to wait for a full support on every platform of the universe.
New platforms comes rarely, and when they do we still have to validate and
adapt -- especially for library things, this is not difficult as we already
have in place a compatibility layer where adding missing things is easy
(excepted for things like <tgmath.h> which needs compiler support, I'm more
conservative there). Due to other dependancies, they usually have already
all what we need. As a matter of fact, known dependancies are usually not
the problem at this stage, bugs -- both in our code and in the
implementation -- and unknown dependancies are the problems. This put also
a little more pressure on the vendor to support C99. Obviously, such kind
of decisions depends on the context, if you are a provider of libraries in
source form, you have quite other constraints than if you provide complete
systems, hardware and software combined.

Yours,

 

[Mark McIntyre]

but it's not far off. Those people who have to port non-Windows-specific
programs to Windows usually avoid Visual C++, and those people who use
Visual C++ usually don't care about porting or creating non-Windows-specific
programs.

As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly. The final code is however
recompiled for Solaris and Linux. This forces a pretty strict rigour
on us, and boy does it sting when you do an overnight build and some
dork has used an MS specific extension.

In short, whether Microsoft implements C99 may matter to Windows
programmers, but to the general issue it matters only slightly.

We have to recompile using various versions of gcc, and knowing that
all three platforms' compilers supported the same Standard woudl be
pretty useful.
--
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

 

[Mark McIntyre]

From the Windows XP EULA: "Microsoft warrants that the Software will
perform substantially in accordance with the accompanying materials for a
period of ninety (90) days from the date of receipt."

"substantially" and "from the date of receipt". Receiptby whom - the
retailer? The wholesaler? Who judges substantially? Microsoft? And
what accompanying materials? I got Win2K in a box with a CD, a
200-language guarantee card, the EULA and a wafer-thin installation
guide which took me through as far as booting from the CD.

Plus it dies after 90 days. Whoop de do. Just long enough to get it
installed.
--
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]

Hi All

What is C99 Standard is all about. is it portable, i mean i saw
-std=C99 option in GCC
but there is no such thing in VC++.?

which one is better ANSI C / C99?
can i know the major difference between C99 & ANSI C standards?

197* K&R1 C book

1988 K&R 2 book }
1989 ANCI-C (C89) US standard ) All basically the
same.
1990 ISO C (C90) International Standard }

K&R were on the ANSI committee and their publisher was faster than the
ANSI system. ANSI is the local US standard and this was superseded by
ISO C 9899:1990 the ANSI and ISO standards are identical in content
for the most part.

1993/5/6 There were Amendment 1 and some TC's to the ISO Standard
this is where most compilers are now.

1999 ISO produced 9899:1999 the current ISO C standard. (There is are
ANSI, BSI, DIN etc versions)

Out of the many C compilers in use only a handful (6 I think) have full
C99 compliance. The other 95+% have implemented SOME C99 things. Gcc
is not different.

Interestingly Quite a few C95+ compilers actually use a fully C99
compliant front end but until their users actual demand C99 it is not
likely to happen their users are asking for other things ahead of C99
compliance.

So to answer your question ANSI C became superseded in 1990. You need
to ask which is better C90/95 or [close to] C99 for your use.


Regards
Chris

 

[Chris Hills]

jacob navia said:


So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.

I think there are half a dozen fully conforming C99 compilers. Compared
to the 100 or so that aren't

Te problem is in real world engineering few really care if the compiler
is C99 conforming. If the industry did care then the compiler makers
would do it.

 

[Chris Hills]

* Richard Heathfield wrote, On 28.09.2006 21:57:

I didn't spend much time on this, but have a few comments which I
believe are more or less correct:
- The EDG compiler *front end* is used by (lots of ?) vendors of
embedded systems, so C99 support for embedded systems may be better
than we think.

None of the embedded compilers that use the EDG front end do a full
implementation of C99 the do C95+ a bit.

- The Dinkumware C99 library claims to be portable. I was unable to
find a list of supported platforms, but assume that it is portable to
more platforms than the next version of Linux...

Several embedded compilers use this library.


Though there are components that are C99 it does not mean the compiler
suite they are used on is C99 compliant.

 

[Richard Heathfield]

Jean-Marc Bourguet said:

I've quite another approach: when one feature is usefull, I check to see
if
it is supported on all the target platforms and if it is, I use it.

That works for me, too, provided the list of target platforms is
sufficiently stable, and provided my client is prepared to meet the costs
of migrating to those new compilers (by no means all clients relish the
idea of changing to a new compiler just because one of their contract guys
tells them to - and rightly so).

Obviously, such kind
of decisions depends on the context, if you are a provider of libraries in
source form, you have quite other constraints than if you provide complete
systems, hardware and software combined.

You've hit the nail on the head.

 

[Richard Heathfield]

Chris Hills said:

I think there are half a dozen fully conforming C99 compilers. Compared
to the 100 or so that aren't

Yes, I've now seen the list, the sheer dearthiness of which is awesome.

Te problem is in real world engineering few really care if the compiler
is C99 conforming. If the industry did care then the compiler makers
would do it.

Right. After all, it's not as if C99 has anything that is obviously "gimme
gimme gimme".

 

[Skarmander]

As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly.

Not so friendly that it could be used to invoke a different compiler? The
IDE and the compiler are still separate, despite appearances to the
contrary. (The latest incarnations feature tighter integration, a la Eclipse
-- but then, you could use Eclipse for that matter).

The final code is however recompiled for Solaris and Linux. This forces a
pretty strict rigour on us, and boy does it sting when you do an
overnight build and some dork has used an MS specific extension.

See, I don't get this. You actually let the GUI waste your time like that?
Setting up mingw with a separate IDE would be too much work? It might save
you a few overnight suprises.

S.

 

[Ian Collins]

As a counterexample, we do a lot of development in Visual C++ because
the GUI is easy to use, and friendly. The final code is however
recompiled for Solaris and Linux.

Both of which support parallel/distributed builds. I work the other
way, use the faster build and test environment on Solaris, recompile for
windows.
This forces a pretty strict rigour

on us, and boy does it sting when you do an overnight build and some
dork has used an MS specific extension.

Overnight build? What are you building?

 

[lawrence.jones]

K&R were on the ANSI committee

No, they were not. Not even one of them. Not even as observers.
Dennis came to exactly one meeting, very late in the process, to ensure
that the committee didn't make a stupid mistake, and my recollection is
that he didn't even speak since the committee had already recognized the
error of their ways.

-Larry Jones

No one can prove I did that!! -- Calvin

 

[Michael Mair]

Both of which support parallel/distributed builds. I work the other
way, use the faster build and test environment on Solaris, recompile for
windows.

Not that I recommend the "VC++ build first" strategy, but there
are add-ons like IncrediBuild which supports distributed building
and gives you a chance to have debug information if the limits of
VC6 are exhausted. Unfortunately, it does not work well with code
coverage tools.
Thus, your limit is the linking time (which is non-negligible for
sufficiently large applications/DLLs).

This forces a pretty strict rigour

I can imagine that

Overnight build? What are you building?

I don't know what Mark is at.
Sometimes, you need overnight builds because you need "stable"
phases for reproducible configurations and test runs.

When breaking a DLL into several smaller DLLs, every design sin
of the last x years must be paid for in that you have DLL interfaces
affecting half the project (at least until you fixed that). This
necessitates times when nobody is checking in, so everyone can get
consistent sources.


Cheers
Michael

 

[CBFalconer]

It is the current C standard, as defined by ANSI/ISO. The old
standard (C89) is now obsolete.

Obsolete is not the best word here. Has been replaced by C99 is
probably more accurate.

Yes. There are compilers for it under linux, windows, and many
other operating systems and implementations. Microsoft doesn't
implement it, but you can find compilers like intel compiler
that implements it. Comeau C/C++ implements C99 also.


VC++ doesn't care about C development and has abandonend
most C development to concentrate on C# C++ and other languages.


C99 offers most of the all standard (including warts like gets())
and adds significant functionality.


http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html

This is a good post, IMO. The fact that most compiler vendors have
not yet implemented C99 is not really germane, and is probably our
(collective) fault, in that we have not insisted on compliance with
the current standard.

To all practical purposes the closest we can get to a C99
implementation is gcc. However that is hampered by the fact that
gcc depends on the libraries present on most systems, and this
prevents full compliance. As a simple example the usual printf
interpreter (in a library) can be expected to implement C90, but
probably not C99, because C99 did not exist when that interpreter
was written.

The fact is that programs written to the C99 standard are portable
to all compiler systems that comply with C99, while all programs
written to the C95 standard are portable to all compiler systems
that comply with C95, etc. for C90 and C89. C90 and C89 differ
only in the numbering of the standard sections. In general we can
expect later standards to handle programs written to earlier
standards.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Ian Collins]

Not that I recommend the "VC++ build first" strategy, but there
are add-ons like IncrediBuild which supports distributed building
and gives you a chance to have debug information if the limits of
VC6 are exhausted. Unfortunately, it does not work well with code
coverage tools.

I'm not sure what the "VC++ build first" strategy is, care to explain?

 

[CBFalconer]

Mark McIntyre wrote:
.... snip ...


See, I don't get this. You actually let the GUI waste your time
like that? Setting up mingw with a separate IDE would be too much
work? It might save you a few overnight suprises.

No, you don't appreciate the actual situation. Some pointy haired
type has hired you as a consultant, and won't let you rampage
through his computer systems installing software. He won't even
let you develop on your own machinery and bring the result in on
some media or other. Thus you are limited to what he has been sold
by the evil empire.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[CBFalconer]

jacob navia said:

So far, then, we have exactly ZERO conforming implementations of
C99. So much for that.

Ah, but who can say whether we have any conforming implementations
of c90, or C95. In the absence of a generally available test
suite, which anyone reasonably competent can run, to verify
compliance we cannot really make any such statements. We know we
can find failings in all alleged "C99" implementations. At least
with gcc we have a document available spelling out the known
failings with regard to C99.

Quid custodes costodiens applies.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Michael Mair]

I'm not sure what the "VC++ build first" strategy is, care to explain?

Sorry, I meant the fact that they (Mark's department) develop under
VC++ and then try it out on their target implementation.

Cheers
Michael

 

[Richard Heathfield]

CBFalconer said:

Ah, but who can say whether we have any conforming implementations
of c90, or C95. In the absence of a generally available test
suite, which anyone reasonably competent can run, to verify
compliance we cannot really make any such statements. We know we
can find failings in all alleged "C99" implementations. At least
with gcc we have a document available spelling out the known
failings with regard to C99.

Quid custodes costodiens applies.

Do you mean "quis custodies ipsos custodes?" ("who guards the guards
themselves?")? No, it doesn't apply. But yes, you're right, we need to be
able to verify C90 conformance too - not so that we can jump on the
implementors, necessarily, but so that we can be careful about our own
code. For example, I am reasonably sure that Borland's handling of errno is
non-conforming. Because there is a significant chance that my code may be
compiled using Borland's compiler, therefore, I avoid errno like the plague
in my own code. I don't rant and rave about it - I just avoid using that
feature. Same with C99 features, really. I don't worry too much about
certification - I just use the features I know to be portable to all the
implementations on which my code is likely to be compiled.

 

[Richard Heathfield]

CBFalconer said:

No, you don't appreciate the actual situation. Some pointy haired
type has hired you as a consultant, and won't let you rampage
through his computer systems installing software. He won't even
let you develop on your own machinery and bring the result in on
some media or other. Thus you are limited to what he has been sold
by the evil empire.

No matter how often I try to explain this to people, they never seem to get
it. "Why don't you just use <foo>?" "Because even though I agree with you
that <foo> is an excellent solution, my chances of getting it through due
process are zero minus, that's why."

Same with compiler warnings. I like to initialise all my objects, to put
them into a known, deterministic state. It makes debugging much easier.
Others say "why not just ask your compiler to diagnose when you're trying
to use a value you haven't written to yet?" - and the answer, of course, is
that I can't guarantee that the implementation I am using /has/ such an
option. (The compiler is not /required/ to diagnose this solution.)