«

On 2011-02-23, Ben Bacarisse <> wrote:
> Seebs <usenet-> writes:
>> I think I'm using some gcc-specific stuff, in fact, I'm actively selecting
>> some GNU extensions from glibc. So I actually run with -std=gnu99.

> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Seebs <usenet-> writes:

> On 2011-02-23, Ben Bacarisse <> wrote:
>> Seebs <usenet-> writes:
>>> I think I'm using some gcc-specific stuff, in fact, I'm actively selecting
>>> some GNU extensions from glibc. So I actually run with -std=gnu99.
<snip>
>> 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.

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.

--
Ben.

Seebs <usenet-> writes:

> On 2011-02-23, Ben Bacarisse <> wrote:
>> Seebs <usenet-> writes:
>>> I think I'm using some gcc-specific stuff, in fact, I'm actively selecting
>>> some GNU extensions from glibc. So I actually run with -std=gnu99.
>
>> 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.

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?

On 2011-02-24, Ben Bacarisse <> wrote:
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Seebs <usenet-> writes:

> On 2011-02-24, Ben Bacarisse <> wrote:
>> 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.

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>
--
Ben.

Ben Bacarisse <> writes:

> Seebs <usenet-> writes:

>> 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.

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.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

Anders Wegge Keller <> writes:

> Ben Bacarisse <> writes:
>
>> Seebs <usenet-> writes:
>
>>> 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.
>
> 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.

--
Ben.

In message <0.a7be5178126de2c18f14.20110225235333GMT.87k4gnoe ma.fsf@bsb.
me.uk>, Ben Bacarisse <> writes
>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.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H <> writes:

> In message <0.a7be5178126de2c18f14.20110225235333GMT.87k4gnoe ma.fsf@bsb.
> me.uk>, Ben Bacarisse <> writes
>>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.

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

--
Ben.

In message <0.cf3d7f85f8372ccd59cd.20110226142334GMT.871v2uoo wp.fsf@bsb.
me.uk>, Ben Bacarisse <> writes
>Chris H <> writes:
>
>> In message <0.a7be5178126de2c18f14.20110225235333GMT.87k4gnoe ma.fsf@bsb.
>> me.uk>, Ben Bacarisse <> writes
>>>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.
>
>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.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/