C99 library issues

C99 library issues

[Paolo Carlini]

Hi,

perusing http://gcc.gnu.org/c99status.html I got the idea that there are some C99 features
still missing from the current GLIBC library, right?

In that case, are there any plans to provide them in GLIBC2.3 ??

Thanks,
Paolo.

Re: C99 library issues

[Andreas Jaeger]

Paolo Carlini <pcarlini@unitus.it> writes:

> Hi,
>
> perusing http://gcc.gnu.org/c99status.html I got the idea that there are some C99 features
> still missing from the current GLIBC library, right?

The note "Library issue" means that this is not a compiler issue.  GCC
supports more systems than glibc based systems.

glibc 2.2.4 should implement all C99 issues, I'm not aware of anything
that's missing.

Perhaps a patch should be added to that page like the appended one. Ok
to commit it?  Or should this get added to the section on "Library
issues" on top of the page?

Andreas

Index: htdocs/c99status.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v
retrieving revision 1.28
diff -u -p -r1.28 c99status.html
--- c99status.html	2001/11/12 22:52:54	1.28
+++ c99status.html	2001/11/19 13:27:27
@@ -374,6 +374,10 @@ implementations to do.  The <code>&lt;st
 <code>&lt;inttypes.h&gt;</code> entries have been separated, but are a
 single entry in C99.</li>
 
+<li>The <a href="http://www.gnu.org/software/libc/libc.html">GNU C
+Library</a> implements all features that are marked as "Library Issue"
+since version 2.2.</li>
+
 </ul>
 
 </body>

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: C99 library issues

[Paolo Carlini]

Hi,

thanks for your feedback. In fact I find particularly misleading some lines in the current
page, to wit, those marked "Library issue" and "Missing". IMHO two patches are in order:
1- That which you propose, clarifying *which* specific implementation of the library is
considered.
2- If you are correct, another one eliminating those entries marked both "Library issue" and
"Missing" , that is,

    wide character library support in <wchar.h>
    and <wctype.h> (originally specified in AMD1)

and

    additional math library functions in <math.h>

Can you take care of this?

Thanks,
Paolo.

Re: C99 library issues

[Joseph S. Myers]

On Mon, 19 Nov 2001, Andreas Jaeger wrote:

> +<li>The <a href="http://www.gnu.org/software/libc/libc.html">GNU C
> +Library</a> implements all features that are marked as "Library Issue"
> +since version 2.2.</li>

trouble.texi already has a similar note.  "Version 2.2 of the GNU C
library includes nearly complete C99 support.".

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: C99 library issues

[Paolo Carlini]

Andreas Jaeger wrote:

> "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
>
> > On Mon, 19 Nov 2001, Andreas Jaeger wrote:
> >
> >> +<li>The <a href="http://www.gnu.org/software/libc/libc.html">GNU C
> >> +Library</a> implements all features that are marked as "Library Issue"
> >> +since version 2.2.</li>
> >
> > trouble.texi already has a similar note.  "Version 2.2 of the GNU C
> > library includes nearly complete C99 support.".
>
> Was this an objection?
>
> The presentation really confuses users,

I admit to be one among them...

> we should mention glibc
> somehow.

Right. And also, at the beginning of the page, a few words to the effect that
lines having only "Library issue" marked indicate a C99 feature which has
*nothing* to do with GCC (this is not obvious, since that WEB page is on the
GCC WEB site!)

Cheers,
Paolo.

Re: C99 library issues

[Jakub Jelinek]

On Mon, Nov 19, 2001 at 02:13:50PM +0100, Paolo Carlini wrote:
> Hi,
> 
> perusing http://gcc.gnu.org/c99status.html I got the idea that there are some C99 features
> still missing from the current GLIBC library, right?
> 
> In that case, are there any plans to provide them in GLIBC2.3 ??

I'd think it is just that c99status.html is not up-to-date with GLIBC 2.2.4.
I believe that the following are DONE:
- wide character library support in <wchar.h> and <wctype.h> (originally
  specified in AMD1) 
- library functions in <inttypes.h>
- additional math library functions in <math.h>
- floating-point environment access in <fenv.h>

As for
- deprecate ungetc at the beginning of a binary file
I don't see what should be done to say this is done.

	Jakub

Re: C99 library issues

[Paolo Carlini]

Some more reflections:

1- Probably I'm wrong about the lines marked both "Library issue" and "Missing": a note at the
beginning clearly indicates that "Missing" refers to the compiler, not to the library. Sorry.

2- Since that web page is among the GCC pages ;-), most evidently the whole "Library" column is
about library-issues-of-interest-to-the-gcc-developers, that is needing at least *some* form of
GCC support. Therefore the patch Andreas proposed is not needed, after all ?!?

... and the page is ok as is...

Perhaps just a clarification at the beginning regarding my interpretation in 2- ??

What do you believe??

Thanks,
Paolo.

Re: C99 library issues

[Paolo Carlini]

... unpolitely replying to myself to complete the description of my current point of view...

> 2- Since that web page is among the GCC pages ;-), most evidently the whole "Library" column is
> about library-issues-of-interest-to-the-gcc-developers, that is needing at least *some* form of
> GCC support. Therefore the patch Andreas proposed is not needed, after all ?!?

... but, if this is the case, those lines marked *only* "Library issue" do not make sense and
should be eliminated, because either they are really about the compiler support - which must be
either "Done", "Missing" or "Broken" - either are about the library itself, but this is not the
point of the page...

Cheers,
Paolo.

Re: C99 library issues

[Joseph S. Myers]

On Mon, 19 Nov 2001, Jakub Jelinek wrote:

> I believe that the following are DONE:
> - wide character library support in <wchar.h> and <wctype.h> (originally
>   specified in AMD1) 

The "Missing" means the lack of format checking for
wprintf/wscanf/wcsftime, as explained below on the page.

> - library functions in <inttypes.h>

Nothing to do with GCC that glibc has this done.

> - additional math library functions in <math.h>

Not math_errhandling (not a function, but the nearest place to put it).

> - floating-point environment access in <fenv.h>

Nothing to do with GCC that glibc has it done (we could do with #pragma 
STDC FENV_ACCESS, but that goes under standard pragmas in the list).

> - deprecate ungetc at the beginning of a binary file

For non-library issues we'd just mark it Done anyway - as it is there's no
relevant compiler support so having just the Library Issue column is
correct.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: C99 library issues

[Geoff Keating]

> Date: Mon, 19 Nov 2001 14:34:48 +0100
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: libc-alpha@sources.redhat.com, gcc@gcc.gnu.org

> As for
> - deprecate ungetc at the beginning of a binary file
> I don't see what should be done to say this is done.

There is a documentation issue; how about this?

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

===File /home/geoffk/patches/cygnus/glibc-c99ungetcbin.patch===
2001-11-19  Geoff Keating  <geoffk@redhat.com>

	* manual/stdio.texi (How Unread): Document that ungetc on
	a binary-mode file is unportable.

Index: libc/manual/stdio.texi
===================================================================
RCS file: /cvs/glibc/libc/manual/stdio.texi,v
retrieving revision 1.130
diff -p -u -u -p -r1.130 stdio.texi
--- stdio.texi	2001/10/29 15:56:29	1.130
+++ stdio.texi	2001/11/19 20:01:41
@@ -1383,9 +1383,10 @@ If @var{c} is @code{EOF}, @code{ungetc} 
 The character that you push back doesn't have to be the same as the last
 character that was actually read from the stream.  In fact, it isn't
 necessary to actually read any characters from the stream before
-unreading them with @code{ungetc}!  But that is a strange way to write
-a program; usually @code{ungetc} is used only to unread a character
-that was just read from the same stream.
+unreading them with @code{ungetc}!  But that is a strange way to write a
+program; usually @code{ungetc} is used only to unread a character that
+was just read from the same stream.  The GNU C library supports this
+even on files opened in binary mode, but other systems might not.
 
 The GNU C library only supports one character of pushback---in other
 words, it does not work to call @code{ungetc} twice without doing input
============================================================

Re: C99 library issues

[Joseph S. Myers]

On Mon, 19 Nov 2001, Paolo Carlini wrote:

> perusing http://gcc.gnu.org/c99status.html I got the idea that there are some C99 features
> still missing from the current GLIBC library, right?
> 
> In that case, are there any plans to provide them in GLIBC2.3 ??

The page has nothing to do with glibc or any other C library.  For glibc's
C99 support you should look at CONFORMANCE in the libc source instead.  I 
believe that the only feature missing in glibc is math_errhandling 
(needing compiler support, as the links in c99status.html explain).

"Library Issue" on its own means there's nothing for the compiler to do.  
"Library Issue" and another column means that the compiler has something
to do to support the library.  This is explained in the second paragraph
of that page.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: C99 library issues

[Paolo Carlini]

"Joseph S. Myers" wrote:

> On Mon, 19 Nov 2001, Paolo Carlini wrote:
>
> > perusing http://gcc.gnu.org/c99status.html I got the idea that there are some C99 features
> > still missing from the current GLIBC library, right?
> >
> > In that case, are there any plans to provide them in GLIBC2.3 ??
>
> The page has nothing to do with glibc or any other C library.  For glibc's
> C99 support you should look at CONFORMANCE in the libc source instead.  I
> believe that the only feature missing in glibc is math_errhandling
> (needing compiler support, as the links in c99status.html explain).

Yes, thanks.
Very slowly I arrived to same conclusion my self (I wrote that somewhere in the GCC lists).
Sorry again for the noise I produced.

> "Library Issue" on its own means there's nothing for the compiler to do.

This explanation could be perhaps added at the beginning of the web page just before the next
one, that about the lines having other fields marked too??

Paolo.

Re: C99 library issues

[Martin v. Loewis]

> perusing http://gcc.gnu.org/c99status.html I got the idea that there
> are some C99 features still missing from the current GLIBC library,
> right?

The URL you cite certainly did not mean to imply anything about glibc.
Instead, it merely tells what parts of C99 are library issues, rather
than compiler issues. "library" could be glibc, but could also be the
Solaris system library, or the Cygnus newlib library.

Regards,
Martin

Re: C99 library issues

[Paolo Carlini]

Gerald Pfeifer wrote:

> On Mon, 19 Nov 2001, Andreas Jaeger wrote:
> > Here's an updated patch following your suggestions.
>
> Looks okay, though we should address the issue of those other entries
> that read "Library Issue -- Done" as well to be consistent, shouldn't
> we?

Hi and thanks for your feedback.
I have just posted a couple of messages which explain my current point of view on
this issue, which, I must admit, I don't yet completely understand:

    http://gcc.gnu.org/ml/gcc/2001-11/msg00869.html
    http://gcc.gnu.org/ml/gcc/2001-11/msg00873.html

Perhaps, the page is mostly ok as it is (sorry Joseph for the noise!), apart of
adding a comment at the end clarifying that the required Library functions are
completely implemented by glibc2.2 and one at the beginning indicating that those
lines marked *only* "Library issue" and nothing else are reported only for
completeness but not really something of interest to the GCC developers since
*purely* library issues...

Thanks,
Paolo.

Re: C99 library issues

[Paolo Carlini]

"Joseph S. Myers" wrote:

> On Mon, 19 Nov 2001, Andreas Jaeger wrote:
>
> > Was this an objection?
> >
> > The presentation really confuses users, we should mention glibc
> > somehow.
>
> Actually, I don't see that we do need to mention glibc.  All we should
> need to do is (a) make it clear what "Library Issue" on its own means; (b)
> make it clear that the list only relates to GCC and people should get
> information from their library supplier about what features their library
> supports (using GCC's support where appropriate to implement them).  If
> there's a link to glibc, I think it should be to the CONFORMANCE file in
> cvsweb rather than making any simplified statement about what particular
> versions support.

Well, everything considered (in particular the thorny issue of the GCC -
GLIBC incompatibility, *not* solved to date, which make clear that GCC and
GLIBC are two projects in principle unrelated) I think that what Joseph is
proposing is a very satisfying solution.

(I believe I'm entitled to take formally position only because I started
myself this thread)

Thanks,
Paolo.