Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > compile error

Reply
Thread Tools

compile error

 
 
Seebs
Guest
Posts: n/a
 
      02-24-2011
On 2011-02-23, Ben Bacarisse <(E-Mail Removed)> wrote:
> Seebs <(E-Mail Removed)> 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 / http://www.velocityreviews.com/forums/(E-Mail Removed)
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.
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-24-2011
Seebs <(E-Mail Removed)> writes:

> On 2011-02-23, Ben Bacarisse <(E-Mail Removed)> wrote:
>> Seebs <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      02-24-2011
Seebs <(E-Mail Removed)> writes:

> On 2011-02-23, Ben Bacarisse <(E-Mail Removed)> wrote:
>> Seebs <(E-Mail Removed)> 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?

 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      02-25-2011
On 2011-02-24, Ben Bacarisse <(E-Mail Removed)> 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 / (E-Mail Removed)
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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-25-2011
Seebs <(E-Mail Removed)> writes:

> On 2011-02-24, Ben Bacarisse <(E-Mail Removed)> 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.
 
Reply With Quote
 
Anders Wegge Keller
Guest
Posts: n/a
 
      02-26-2011
Ben Bacarisse <(E-Mail Removed)> writes:

> Seebs <(E-Mail Removed)> 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.*
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-26-2011
Anders Wegge Keller <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>
>> Seebs <(E-Mail Removed)> 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.
 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      02-26-2011
In message <0.a7be5178126de2c18f14.20110225235333GMT.87k4gnoe ma.fsf@bsb.
me.uk>, Ben Bacarisse <(E-Mail Removed)> 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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-26-2011
Chris H <(E-Mail Removed)> writes:

> In message <0.a7be5178126de2c18f14.20110225235333GMT.87k4gnoe ma.fsf@bsb.
> me.uk>, Ben Bacarisse <(E-Mail Removed)> 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.
 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      02-26-2011
In message <0.cf3d7f85f8372ccd59cd.20110226142334GMT.871v2uoo wp.fsf@bsb.
me.uk>, Ben Bacarisse <(E-Mail Removed)> writes
>Chris H <(E-Mail Removed)> writes:
>
>> In message <0.a7be5178126de2c18f14.20110225235333GMT.87k4gnoe ma.fsf@bsb.
>> me.uk>, Ben Bacarisse <(E-Mail Removed)> 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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
compile directive for conditional compile for Java 1.4 versus Java 5 timjowers Java 7 02-02-2011 12:08 AM
How to compile the following source code in VC6// I have error inVC++6 but compile ok in GCC fAnSKyer C++ 2 06-07-2009 07:57 AM
computation at compile time i.e. compile time functions usingtemplates Carter C++ 2 03-04-2009 06:43 PM
Compile versus not compile (VS 2005)?? stupid48@gmail.com ASP .Net 1 04-11-2008 08:24 PM
cant compile on linux system.cant compile on cant compile onlinux system. Nagaraj C++ 1 03-01-2007 11:18 AM



Advertisments