compile error

[Seebs]

But that changes the language as well as the library.
Yes.

Is it not
possible to use std=c99 and turn on the library extensions with macros?
Maybe what you need is not exactly obtainable but that route, but it
often is.

It might be, but it turns out to be a lot harder for me to get the right
subsets tweaking it by hand.

In terms of the library, no, but a great many more could be made
portable (between compilers) by relying only on library extensions
rather than language ones.

Portability between compilers, given the library extensions, is functionally
a non-issue. I've never heard of anyone actually using glibc with something
other than gcc, but I know lots of people using gcc with things other than
glibc.

I guess... Much though I love standard code, I think it makes a lot of
sense for implementations not to default to a conforming mode on most targets,
because that's almost never a mode in which complete real projects will
compile. Not never, but rarely enough to make it a poor default.

-s

 

[Ben Bacarisse]

Portability between compilers, given the library extensions, is functionally
a non-issue. I've never heard of anyone actually using glibc with something
other than gcc, but I know lots of people using gcc with things other than
glibc.

My point was not about people using glibc with another compiler -- glibc
includes all sorts of things that are available in many other
libraries. I've seen people reject "standard C" because they need some
set of widely available library functions and find that the easiest way
to get that is -std=gnu99 (or to leave off the -std flag altogether).

I should not have phrased it in so personal a way. Your case may rely
specifically on functions only in glibc and not implemented in other
libraries. I should have made the general point that very many more
programs could use standard C rather than the extended languages so may
compilers default to.

I guess... Much though I love standard code, I think it makes a lot of
sense for implementations not to default to a conforming mode on most targets,
because that's almost never a mode in which complete real projects will
compile. Not never, but rarely enough to make it a poor default.

It's possible that history has made this the case -- if language
extensions are available people will use them, sometimes without even
realising it, but I wonder how many programs would build if the default
accepted language were standard C but with all the declarations/
libraries you get with a plain gcc command line.

 

[Tim Rentsch]

It might be, but it turns out to be a lot harder for me to get the right
subsets tweaking it by hand.


Portability between compilers, given the library extensions, is functionally
a non-issue. I've never heard of anyone actually using glibc with something
other than gcc, but I know lots of people using gcc with things other than
glibc.

I guess... Much though I love standard code, I think it makes a lot of
sense for implementations not to default to a conforming mode on most targets,
because that's almost never a mode in which complete real projects will
compile. Not never, but rarely enough to make it a poor default.

Playing devil's advocate for a moment - wouldn't it be
better to have the default be ISO conforming, so that
people would know that they were going to be using
non-portable elements? Besides being made aware of
the issue, being forced to do something about it
might lead to a better choice of which set of
extensions to use (ie, use a narrower set of choices,
or use them only in a restricted set of source
files) -- right? And wouldn't it be better to
raise awareness generally about what is and isn't
portable? As long as it's easy to find out that
extensions are what is needed, and it's easy to
get a reasonably good alternative set, is the
downside really of any great significance?

 

[Seebs]

My point was not about people using glibc with another compiler -- glibc
includes all sorts of things that are available in many other
libraries. I've seen people reject "standard C" because they need some
set of widely available library functions and find that the easiest way
to get that is -std=gnu99 (or to leave off the -std flag altogether).

Ahh, I see.

I should not have phrased it in so personal a way. Your case may rely
specifically on functions only in glibc and not implemented in other
libraries.

Well, insofar as one of my data points is pseudo, yes, rather. (Although
I have it about half working on Darwin now.)

I should have made the general point that very many more
programs could use standard C rather than the extended languages so may
compilers default to.

I am not sure about this. In practice, I don't see much if any code
actually relying on GNU language extensions.

It's possible that history has made this the case -- if language
extensions are available people will use them, sometimes without even
realising it, but I wonder how many programs would build if the default
accepted language were standard C but with all the declarations/
libraries you get with a plain gcc command line.

I'd guess an awful lot of them would, except for the extensions used in
the headers. Of which there are a fair number usually...

-s

 

[Ben Bacarisse]

Ahh, I see.


Well, insofar as one of my data points is pseudo, yes, rather. (Although
I have it about half working on Darwin now.)


I am not sure about this. In practice, I don't see much if any code
actually relying on GNU language extensions.

One of us is missing something. That is exactly my point -- the language
extensions (as opposed to the library extensions) aren't used very much.

<snip>

 

[Anders Wegge Keller]

One of us is missing something. That is exactly my point -- the language
extensions (as opposed to the library extensions) aren't used very much.

Do you consider __attribute__ a language extension? We do not exactly
rely on it, as it's only used to decorate headers (deprecated
functions and format checks), and easily can be #defined into
oblivion. Still, we use it, and with good results.

 

[Ben Bacarisse]

Do you consider __attribute__ a language extension? We do not exactly
rely on it, as it's only used to decorate headers (deprecated
functions and format checks), and easily can be #defined into
oblivion. Still, we use it, and with good results.

Hmm... It's advisory and can, as you say, be defined away. I image its
impact on portability is very low. Quiet different to using typeof or
statement expressions.

 

[Chris H]

In message <0.a7be5178126de2c18f14.20110225235333GMT.87k4gnoema.fsf@bsb.

One of us is missing something. That is exactly my point -- the language
extensions (as opposed to the library extensions) aren't used very much.

I use language extensions all the time in most applications I work on.

A lot of people do.

 

[Ben Bacarisse]

In message <0.a7be5178126de2c18f14.20110225235333GMT.87k4gnoema.fsf@bsb.


I use language extensions all the time in most applications I work on.

A lot of people do.

Not disputed. However I assume you intended to express disagreement
with what I wrote so to save time I'll note that you disagree.

 

[Chris H]

In message <0.cf3d7f85f8372ccd59cd.20110226142334GMT.871v2uoowp.fsf@bsb.

Not disputed. However I assume you intended to express disagreement
with what I wrote so to save time I'll note that you disagree.

In some major areas of programming it is normal to use extensions and
any one who does not is not doing their job.

So saying language extensions are not used very much is plain wrong. It
depends on what is being done.

 

[Ben Bacarisse]

So saying language extensions are not used very much is plain wrong.

Yes, as I said, not disputed. I hope we can continue to agree like this.