From: Uno on
steve wrote:

> The C standard specifies both the compiler and the C library.
> GCC's only concern is the compiler. The developers of glibc
> are worried about the library.
>
> http://gcc.gnu.org/c99status.html
>
> Note, the only item marked broken for the compiler is
> near and dear to your heart.

IEC 60559, a.k.a. IEEE 754 floating point.
> http://gcc.gnu.org/onlinedocs/
>

If I wanted to find the source that goes into glibc, is it in any of the
manuals above?

I have glibc but no decompiler.:-)
--
Uno
From: Nick Maclaren on
In article <81562ad7-fc56-43e4-90ed-80e10f69290b(a)l25g2000prn.googlegroups.com>,
steve <kargls(a)comcast.net> wrote:
>>
>> I am unconvinced that Linux branding means anything, but let that
>> pass. =A0However, gcc is NOT a C99 conforming compiler, though it has
>> several C99 features, and the last I heard was that there was no
>> intent to make it one. =A0As I said, there is no customer interest.
>> That's documented, somewhere.
>
>The C standard specifies both the compiler and the C library.
>GCC's only concern is the compiler. The developers of glibc
>are worried about the library.

That is a distinction that doesn't make a lot of sense, not least
because the boundary between the two in the standard isn't
implementable in a conventional compiler/library model. Several
of the headers are primarily compiler aspects (e.g. <stdarg.h>,
<limits.h>, <float.h>, <fenv.h> and <tgmath.h>).

More importantly, it's not a distinction that is acceptable in
terms of the standard, except insofar that gcc might be a
freestanding system on its own. Yes, I was referring to gcc+glibc,
which is what makes sense in terms of C99.

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

Interesting. There clearly has been a change of intent. As I
said above, the last I heard - I do not track this lunacy on a
regular basis.

>Note, the only item marked broken for the compiler is
>near and dear to your heart.

You have got that spectacularly wrong! I thought that I had made
it clear that I regarded the IEEE 754 support as demented.

I will try to remember what the issue was where C99 was incompatible
with gcc, and there was a definite intent to maintain compatibility
at the expense of C99, and check what has happened to it. But it's
a long time ago now, and I may not be able to.


Regards,
Nick Maclaren.
From: steve on
On Aug 11, 3:00 pm, Uno <merrilljen...(a)q.com> wrote:
> steve wrote:
> > The C standard specifies both the compiler and the C library.
> > GCC's only concern is the compiler.  The developers of glibc
> > are worried about the library.
>
> >http://gcc.gnu.org/c99status.html
>
> > Note, the only item marked broken for the compiler is
> > near and dear to your heart.
>
> IEC 60559, a.k.a. IEEE 754 floating point.
>
> >http://gcc.gnu.org/onlinedocs/
>
> If I wanted to find the source that goes into glibc, is it in any of the
> manuals above?
>
> I have glibc but no decompiler.:-)

If I wanted the source to glibc, I would more than likely
use my favorite search engine with the profoundly obvious
search term 'glibc'.

--
steve
From: steve on
On Aug 11, 3:30 pm, n...(a)gosset.csi.cam.ac.uk (Nick Maclaren) wrote:
> In article <81562ad7-fc56-43e4-90ed-80e10f692...(a)l25g2000prn.googlegroups..com>,
>
> steve  <kar...(a)comcast.net> wrote:
>
> >Note, the only item marked broken for the compiler is
> >near and dear to your heart.
>
> You have got that spectacularly wrong!  I thought that I had made
> it clear that I regarded the IEEE 754 support as demented.

I suppose I should have used a 'smiley' to denote sarcasm.
Yes, I'm well aware of your views concerning ieee754.

--
steve


From: JB on
On 2010-08-11, Nick Maclaren <nmm(a)gosset.csi.cam.ac.uk> wrote:
> In article <81562ad7-fc56-43e4-90ed-80e10f69290b(a)l25g2000prn.googlegroups.com>,
> steve <kargls(a)comcast.net> wrote:
>>>
>>> I am unconvinced that Linux branding means anything, but let that
>>> pass. =A0However, gcc is NOT a C99 conforming compiler, though it has
>>> several C99 features, and the last I heard was that there was no
>>> intent to make it one. =A0As I said, there is no customer interest.
>>> That's documented, somewhere.
>>
>>The C standard specifies both the compiler and the C library.
>>GCC's only concern is the compiler. The developers of glibc
>>are worried about the library.
>
> That is a distinction that doesn't make a lot of sense, not least
> because the boundary between the two in the standard isn't
> implementable in a conventional compiler/library model. Several
> of the headers are primarily compiler aspects (e.g. <stdarg.h>,
><limits.h>, <float.h>, <fenv.h> and <tgmath.h>).
>
> More importantly, it's not a distinction that is acceptable in
> terms of the standard, except insofar that gcc might be a
> freestanding system on its own. Yes, I was referring to gcc+glibc,
> which is what makes sense in terms of C99.

Well, gcc can be used with other C libraries than glibc. glibc is used
only on Linux, AFAICT. That being said, you're right, and this split
has caused some problems in the past (an obvious one in the context of
this discussion being that the level of C99 support is different on
targets using different C libraries), and IMHO it would make sense if
the C standard library would be part of gcc, and then glibc could be
more like some "libposix" are whatever one might call it. But,
anyways, that's not how things are done in reality, largely for
historical reasons I suppose.

> I will try to remember what the issue was where C99 was incompatible
> with gcc, and there was a definite intent to maintain compatibility
> at the expense of C99, and check what has happened to it. But it's
> a long time ago now, and I may not be able to.

The only thing I can recall right away is that there was an
incompatibility with the C99 "inline" and the GCC extension
"inline". IIRC something like the GCC "extern inline" meant the same
thing as just "inline" in C99, and vice versa. But, this issue was
fixed a few years ago, and GCC nowadays by default follows the C99
semantics.


--
JB