Can I use C99 features yet?

[Michael B Allen]

Is it considered a bad idea to use a C99 only feature? It has been almost
6 years right? Specifically I'm interested in variadic macros. All of
my code is C89 (or less) except for my debugging macros.

Thanks,
Mike

 

[Ben Pfaff]

Is it considered a bad idea to use a C99 only feature? It has been almost
6 years right? Specifically I'm interested in variadic macros. All of
my code is C89 (or less) except for my debugging macros.

I'd say that there still aren't enough C99 implementations, if
you want your code to be portable.

 

[websnarf]

Is it considered a bad idea to use a C99 only feature? [...]

Yes. But in this newsgroup its more appropriate to talk about C99
(little more than a figment of some people's imagination) than Visual
C++ or gcc (one of which is almost certainly the compiler you are
using.)

[...] It has been almost 6 years right? [...]

I think technically just a little more than 5 years. But the major
contents were known for about 6 years.

[...] Specifically I'm interested in variadic macros. All of
my code is C89 (or less) except for my debugging macros.

Oh well, sucks to be you. Maybe you could write a portable C
preprocessor with this extension yourself -- that would at least give
some reasonable prospect of portability. The C99 features are just not
portable (almost nobody implements it completely, and its highly
unlikely that any mainstream compiler ever will.) To be portable in C
you have to stick with the 16 year old standard, since the C standard
committee has generally been ignored since then.

Actually, if you are looking for adopting new language features (like
variadic macros) try pushing for them in the next *C++* standard, since
they will then be far more likely to be adopted (and possibly back
ported to the C compiler).

 

[Kevin Bracey]

In message <[email protected]>

Is it considered a bad idea to use a C99 only feature? It has been almost
6 years right? Specifically I'm interested in variadic macros. All of
my code is C89 (or less) except for my debugging macros.

Up to you. It depends whether the implementations you think you're likely to
use in the near future support the particular C99 feature you need.

We use C99 extensively here - mainly the core language stuff like designated
initialisers, VLAs, variadic macros and bool. Also <stdint.h> is very handy,
and snprintf. We use variadic macros for our debugging library.

However, we pretty much only use one compiler. The only other compiler we're
likely to use is gcc, which supports all or most of those features.

Any of the more esoteric stuff, particularly the math parts such as
<complex.h> and Annex F are likely to be far less portable. Most compilers
don't even provide C89 floating-point, let alone C99 Annex F.

Obviously any use of a C99 feature makes your code less portable than using
C89 features. But then, using C89 features makes your code less portable than
pcc code. It's up to you where you think the line should be drawn.

 

[TTroy]

Is it considered a bad idea to use a C99 only feature? It has been almost
6 years right? Specifically I'm interested in variadic macros. All of
my code is C89 (or less) except for my debugging macros.

I've been told that C89 is a subset of C99, so if you stick to C89
rules, you are conforming to C99 (your program will work exactly the
same). I'm not sure if this is EXACTLY true (whether all C89 programs
will compile and then behave the same on a C99 compiler) but I presume
it is "for the most part" true because C89 is still popular (my IDE
doesn't even let me use // comments!)

C89 is a subset of C99
And neither are subsets of any C++ standard.

I think only gcc provides full C99 support.

 

[Clark S. Cox III]

I've been told that C89 is a subset of C99,

You've been told wrong.

so if you stick to C89
rules, you are conforming to C99 (your program will work exactly the
same). I'm not sure if this is EXACTLY true (whether all C89 programs
will compile and then behave the same on a C99 compiler) but I presume
it is "for the most part" true because C89 is still popular (my IDE
doesn't even let me use // comments!)

If C89 is a subset of C99 in the same way that C89 is a subset of C++
(i.e. it isn't). All three languages share many features, but none is a
true subset or superset of either of the others.

Valid C89, invalid C99, invalid C++:

#include <stdio.h>

foo()
{
return 20;
}

main()
{
printf("%d\n", foo());
return 0;
}

Invalid C89, valid C99, invalid C++:

#include <stdio.h>

int main()
{
for(long long i=0; i<50; ++i)
{
printf("%lld\n", i);
}
return 0;
}

 

[E. Robert Tisdale]

No!


I've been told that C89 is a subset of C99
so, if you stick to C89 rules, you are conforming to C99
(your program will work exactly the same).
I'm not sure if this is EXACTLY true (whether all C89 programs
will compile and then behave the same on a C99 compiler)
but I presume it is "for the most part" true
because C89 is still popular
(my IDE doesn't even let me use // comments!)

C89 is a subset of C99
and neither are subsets of any C++ standard.

I think only gcc provides full C99 support.

Not yet. Take a look at

Status of C99 features in GCC

http://gcc.gnu.org/c99status.html

It appears that about 75% of the new features are "done".
I don't care about any of the "missing" features.
None of the "library issues" concern me".
It bothers me that variable-length arrays,
complex (and imaginary) support, IEC 60559 support
and inline functions are "broken"
but I haven't had any trouble with them yet
so I'm not sure that I care about them either.

My conclusion is that
C99 support in GCC is "good enough" for me.

It would be nice to know if there is a subset of C99 features
which are supported well enough by most compilers
to ensure portability.

 

[Keith Thompson]

I think only gcc provides full C99 support.

No, gcc doesn't provide full C99 support.

<http://gcc.gnu.org/c99status.html>

 

[Keith Thompson]

No!

It's a good idea if you can count on the feature being available in
all the implementations you need to use. It's potentially a bad idea
otherwise. A simple "yes" or "no" answer is misleading.

[snip]

My conclusion is that
C99 support in GCC is "good enough" for me.

And each project has to decide for itself whether it's "good enough"
for that project.

It would be nice to know if there is a subset of C99 features
which are supported well enough by most compilers
to ensure portability.

Agreed.

I believe there are some platforms that are not supported by gcc, and
on which the native compiler doesn't support C99 and is unlikely to in
the future. (I think Cray systems are an example, but I'm not sure of
the current status.) On the other hand, not everyone needs to care
about such platforms.

 

[TTroy]

You've been told wrong.


If C89 is a subset of C99 in the same way that C89 is a subset of C++

(i.e. it isn't). All three languages share many features, but none is a
true subset or superset of either of the others.

Valid C89, invalid C99, invalid C++:

#include <stdio.h>

foo()
{
return 20;
}

main()
{
printf("%d\n", foo());
return 0;
}

Yes, I already knew about this case. This was a feature in C89 that
provided backward compatibility to older programs, but the standard did
say these old declarations will probably be removed sometime in the
future. What I really meant is, C89 has a "full set of features" that
is a subset of C99. In your case above, the feature is "definition or
declaring a function" and there are two ways to do it, and one of the
ways is acceptable in C99 too (explicitly declaring everything). So
this doesn't take away from a feature, it just means there is an
alternative that will still allow someone to program C89 such that it
is the same in C99.

Invalid C89, valid C99, invalid C++:

Of course code can be invalid in C89 and valid in C99, because for the
most part, C99 is a superset of C89.

#include <stdio.h>

int main()
{
for(long long i=0; i<50; ++i)
{
printf("%lld\n", i);
}
return 0;
}

Yes, the addition of long long increases the set of available integral
types in C99. That still fits the "subset" notion (C89's types is a
subset of C99's types)

 

[Clark S. Cox III]

Yes, I already knew about this case. This was a feature in C89 that
provided backward compatibility to older programs, but the standard did
say these old declarations will probably be removed sometime in the
future. What I really meant is, C89 has a "full set of features" that
is a subset of C99. In your case above, the feature is "definition or
declaring a function" and there are two ways to do it, and one of the
ways is acceptable in C99 too (explicitly declaring everything). So
this doesn't take away from a feature, it just means there is an
alternative that will still allow someone to program C89 such that it
is the same in C99.

My point still stands that there exists a program that is valid C89,
but is not valid C99. Therefore, by definition, C89 cannot be a subset
of C90.

int main()
{
float inline = 15.0;
int restrict = inline * 0;

return restrict;
}

 

[infobahn]

My point still stands that there exists a program that is valid C89,
but is not valid C99. Therefore, by definition, C89 cannot be a subset
of C90.

ITYM "of C99".

 

[one2001boy]

In message <[email protected]>



Up to you. It depends whether the implementations you think you're likely to
use in the near future support the particular C99 feature you need.

We use C99 extensively here - mainly the core language stuff like designated
initialisers, VLAs, variadic macros and bool. Also <stdint.h> is very handy,
and snprintf. We use variadic macros for our debugging library.

However, we pretty much only use one compiler. The only other compiler we're
likely to use is gcc, which supports all or most of those features.

Any of the more esoteric stuff, particularly the math parts such as
<complex.h> and Annex F are likely to be far less portable. Most compilers
don't even provide C89 floating-point, let alone C99 Annex F.

If you want to try <complex.h> and Annex F, you can take a look at free
C/C++ interpreter ch. it runs in Windows, Linux, Solaris, HP-UX,
FreeBSD, Mac OS X and QNX.

http://www.softintegration.com/demos/chstandard/c99.html

Also, there is an article published in DDJ about C99 numeric and its
implementation.
http://www.softintegration.com/docs/whitepaper/j_ddj.pdf

 

[one2001boy]

Not yet. Take a look at

Status of C99 features in GCC

http://gcc.gnu.org/c99status.html

It appears that about 75% of the new features are "done".
I don't care about any of the "missing" features.
None of the "library issues" concern me".
It bothers me that variable-length arrays,
complex (and imaginary) support, IEC 60559 support
and inline functions are "broken"
but I haven't had any trouble with them yet

variable-length arrays (VLA) and complex are supported in C/C++
interpreter Ch. However, it is not a compiler.

The supported C99 features can be found at
http://www.softintegration.com/demos/chstandard/c99.html

not sure if it is helpful.

 

[Kenny McCormack]

I've been told that C89 is a subset of C99,

You've been told wrong.

so if you stick to C89
rules, you are conforming to C99 (your program will work exactly the
same). I'm not sure if this is EXACTLY true (whether all C89 programs
will compile and then behave the same on a C99 compiler) but I presume
it is "for the most part" true because C89 is still popular (my IDE
doesn't even let me use // comments!)

If C89 is a subset of C99 in the same way that C89 is a subset of C++
(i.e. it isn't). All three languages share many features, but none is a
true subset or superset of either of the others.[/QUOTE]

In reality, you will never get a true subset relation in either direction
(and I am leaving C++ out of it for now, as it is, of course, OT), because
each new standard will always do both of the following:
1) Tighten up the syntax (thereby breaking some old programs)
2) Add new features (which obviously weren't present in earlier
versions)

 

[Randy Howard]

In reality, you will never get a true subset relation in either direction
(and I am leaving C++ out of it for now, as it is, of course, OT), because
each new standard will always do both of the following:
1) Tighten up the syntax (thereby breaking some old programs)
2) Add new features (which obviously weren't present in earlier
versions)

Shortly, if it hasn't practically happened already, whatever gcc will
accept will become "the C language standard". I know, heresy. End
of the world. Call in the national guard. The sheer volume of code
being written in it will make it a de facto standard the way MS
practices have been in the past (and very likely will continue).

 

[nm]

I'd say that there still aren't enough C99 implementations, if
you want your code to be portable.

That's an opinion! No opinions here! That has nothing to do with how
the language works! Off topic! Off topic!

 

[CBFalconer]

That's an opinion! No opinions here! That has nothing to do
with how the language works! Off topic! Off topic!

Bravo. A well earned PLONK.

 

[Martin Ambuhl]

That's an opinion! No opinions here! That has nothing to do with how
the language works! Off topic! Off topic!

I always regret adding anyone to my killfile, but some people are so
stupid that I really have no choice.
*plonk*