C99 Status - inttypes.h

C99 Status - inttypes.h

[Diogo Sousa]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

Hi,

I checked the "library functions in <inttypes.h>" item in c99status
(marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it
seems that glibc implements everything the standard demands.

Am I missing something or is this outdated? If so, where can I find more
information about it?

Thank you,
Diogo Sousa


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: C99 Status - inttypes.h

[Joseph S. Myers]

On Thu, 21 Jul 2011, Diogo Sousa wrote:

> Hi,
> 
> I checked the "library functions in <inttypes.h>" item in c99status
> (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it
> seems that glibc implements everything the standard demands.
> 
> Am I missing something or is this outdated? If so, where can I find more
> information about it?

"Library Issue" simply means it's not GCC's resposibility; it says nothing 
about the state in any particular library that may be used with GCC.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: C99 Status - inttypes.h

[Basile Starynkevitch]

On Thu, 21 Jul 2011 15:24:00 +0100
Diogo Sousa <diogogsousa@gmail.com> wrote:


 
> I checked the "library functions in <inttypes.h>" item in c99status
> (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it
> seems that glibc implements everything the standard demands.
 
> Am I missing something or is this outdated? If so, where can I find more
> information about it?

This brings another question. Can a GCC pass use intptr_t (the standard int of the same
size as a void* pointer)? This is quite useful, for instance when one wants to compute an
hash, or a unique sorted rank (to be used inside B-trees) from the address of a gimple
or a tree.

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: C99 Status - inttypes.h

[Joe Buck]

On Thu, Jul 21, 2011 at 07:30:16AM -0700, Joseph S. Myers wrote:
> On Thu, 21 Jul 2011, Diogo Sousa wrote:
> 
> > Hi,
> > 
> > I checked the "library functions in <inttypes.h>" item in c99status
> > (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it
> > seems that glibc implements everything the standard demands.
> > 
> > Am I missing something or is this outdated? If so, where can I find more
> > information about it?
> 
> "Library Issue" simply means it's not GCC's resposibility; it says nothing 
> about the state in any particular library that may be used with GCC.

But readers will focus on the word "Issue" here and think that there is
something missing.  Perhaps there should be a footnote explaining that
glibc/eglibc has the needed support, but that other libraries might not.

Re: C99 Status - inttypes.h

[Ian Lance Taylor]

Basile Starynkevitch <basile@starynkevitch.net> writes:

> This brings another question. Can a GCC pass use intptr_t (the standard int of the same
> size as a void* pointer)? This is quite useful, for instance when one wants to compute an
> hash, or a unique sorted rank (to be used inside B-trees) from the address of a gimple
> or a tree.

Yes.  There are a number of uses of intptr_t already in the gcc source
code.  We can get away with this because the configure script uses
AC_TYPE_INTPTR_T (via GCC_STDINT_TYPES).

Ian

Re: C99 Status - inttypes.h

[Diogo Sousa]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On 07/21/2011 06:44 PM, Joe Buck wrote:
> On Thu, Jul 21, 2011 at 07:30:16AM -0700, Joseph S. Myers wrote:
>> On Thu, 21 Jul 2011, Diogo Sousa wrote:
>>
>>> Hi,
>>>
>>> I checked the "library functions in <inttypes.h>" item in c99status
>>> (marked as "Library Issue") [http://gcc.gnu.org/c99status.html], and it
>>> seems that glibc implements everything the standard demands.
>>>
>>> Am I missing something or is this outdated? If so, where can I find more
>>> information about it?
>>
>> "Library Issue" simply means it's not GCC's resposibility; it says nothing 
>> about the state in any particular library that may be used with GCC.
> 
> But readers will focus on the word "Issue" here and think that there is
> something missing.  Perhaps there should be a footnote explaining that
> glibc/eglibc has the needed support, but that other libraries might not.
> 

I agree. It should say something as "Library Dependent", and report
glibc status.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: C99 Status - inttypes.h

[Paulo J. Matos]

On 22/07/11 00:47, Diogo Sousa wrote:
>>
>> But readers will focus on the word "Issue" here and think that there is
>> something missing.  Perhaps there should be a footnote explaining that
>> glibc/eglibc has the needed support, but that other libraries might not.
>>
>
> I agree. It should say something as "Library Dependent", and report
> glibc status.
>

I have to disagree, library issue means that it's an issue with the 
library, not gcc. Also, gcc should not list the status of a specific 
library since there are so many that can be used besides glibc and it 
would require someone to update it in case the status of that specific 
library changes for a given feature.

Might be ok to do this in a wiki but in the main gcc documentation I 
think it's good as it is.

-- 
PMatos

Re: C99 Status - inttypes.h

[Joern Rennecke]

Quoting "Paulo J. Matos" <pocmatos@gmail.com>:

> On 22/07/11 00:47, Diogo Sousa wrote:
>>>
>>> But readers will focus on the word "Issue" here and think that there is
>>> something missing.  Perhaps there should be a footnote explaining that
>>> glibc/eglibc has the needed support, but that other libraries might not.
>>>
>>
>> I agree. It should say something as "Library Dependent", and report
>> glibc status.
>>
>
> I have to disagree, library issue means that it's an issue with the
> library, not gcc.

It still makes sense to clarify the language to indicate that, depending on
the library used, this might be, in fact, a library non-issue.

> Also, gcc should not list the status of a specific
> library since there are so many that can be used besides glibc and it
> would require someone to update it in case the status of that specific
> library changes for a given feature.

I agree that trying to track every library there would be a maintenance
burden, but giving one example of a library that works is meaningful.
And, since GCC is still a GNU project, mentioning the status of GNU libc
doesn't seem that arbitrary.

Re: C99 Status - inttypes.h

[Paulo J. Matos]

On 22/07/11 16:22, Joern Rennecke wrote:
>> I have to disagree, library issue means that it's an issue with the
>> library, not gcc.
>
> It still makes sense to clarify the language to indicate that, depending on
> the library used, this might be, in fact, a library non-issue.
>

We might be interpreting this differently. When I you it's a "library 
issue", I understand it as begin something that has to do with the 
library, not that it is a definite problem with the library. Therefore 
if I want to see what's the feature status I should check the library 
documentation. I didn't think that saying it is a library issue would 
mean that it is definitely broken/missing in the library.

Then again my native language is not english. However, by raising this 
you're proving your point. If we can avoid different interpretations 
then better.

> I agree that trying to track every library there would be a maintenance
> burden, but giving one example of a library that works is meaningful.
> And, since GCC is still a GNU project, mentioning the status of GNU libc
> doesn't seem that arbitrary.

Even just listing the status of a single feature from GNU libc might be 
dangerous. You're duplicating information that's probably available in 
the manual anyway and risk publicizing out-dated information. Also, 
you'll need someone to volunteer to keep track of the status of every 
feature in glibc that's listed a library issue in the c99 page. A better 
way to do this if you want to mention glibc would be to link to glibc 
documentation directly. Something like:

"Status of this feature in glibc <http://.../libc/manual/...>"

-- 
PMatos

Re: C99 Status - inttypes.h

[James Dennett]

On Fri, Jul 22, 2011 at 8:37 AM, Paulo J. Matos <pocmatos@gmail.com> wrote:
> On 22/07/11 16:22, Joern Rennecke wrote:
>>>
>>> I have to disagree, library issue means that it's an issue with the
>>> library, not gcc.
>>
>> It still makes sense to clarify the language to indicate that, depending
>> on
>> the library used, this might be, in fact, a library non-issue.
>>
>
> We might be interpreting this differently. When I you it's a "library
> issue", I understand it as begin something that has to do with the library,
> not that it is a definite problem with the library. Therefore if I want to
> see what's the feature status I should check the library documentation. I
> didn't think that saying it is a library issue would mean that it is
> definitely broken/missing in the library.
>
> Then again my native language is not english. However, by raising this
> you're proving your point. If we can avoid different interpretations then
> better.

While your use of the term "a library issue" meaning roughly "the
responsibility of the library" is entirely correct, unfortunately the
term "issue" has been hijacked of late as a euphemism for "problem",
which leaves us without a good, unambiguous way to refer to issues
that may not, in fact, be problems.

-- James

RE: C99 Status - inttypes.h

[Weddington, Eric]

> -----Original Message-----
> From: Joern Rennecke [mailto:amylaar@spamcop.net]
> Sent: Friday, July 22, 2011 9:22 AM
> To: Paulo J. Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: C99 Status - inttypes.h
> 
> I agree that trying to track every library there would be a maintenance
> burden, but giving one example of a library that works is meaningful.
> And, since GCC is still a GNU project, mentioning the status of GNU libc
> doesn't seem that arbitrary.

Realistically, how many unique libraries are used for all of the GCC targets? I would think that it has to be some low, finite number.

Re: C99 Status - inttypes.h

[Eric Botcazou]

> Realistically, how many unique libraries are used for all of the GCC
> targets? I would think that it has to be some low, finite number.

There is at least one per OS (Linux, Solaris, HP-UX, IRIX, Tru64, *BSD, VMS, 
Windows, etc) plus variants depending on the version of the OS.

-- 
Eric Botcazou

RE: C99 Status - inttypes.h

[Weddington, Eric]

> -----Original Message-----
> From: Eric Botcazou [mailto:ebotcazou@adacore.com]
> Sent: Saturday, July 23, 2011 1:28 PM
> To: Weddington, Eric
> Cc: gcc@gcc.gnu.org; Joern Rennecke; Paulo J. Matos
> Subject: Re: C99 Status - inttypes.h
> 
> > Realistically, how many unique libraries are used for all of the GCC
> > targets? I would think that it has to be some low, finite number.
> 
> There is at least one per OS (Linux, Solaris, HP-UX, IRIX, Tru64, *BSD,
> VMS,
> Windows, etc) plus variants depending on the version of the OS.

Thanks. I stand corrected. :-)

Re: C99 Status - inttypes.h

[Gerald Pfeifer]

On Fri, 22 Jul 2011, Joern Rennecke wrote:
>>>> But readers will focus on the word "Issue" here and think that there is
>>>> something missing.  Perhaps there should be a footnote explaining that
>>>> glibc/eglibc has the needed support, but that other libraries might not.
>>> I agree. It should say something as "Library Dependent", and report
>>> glibc status.
> It still makes sense to clarify the language to indicate that, depending on
> the library used, this might be, in fact, a library non-issue.
> [...]
> I agree that trying to track every library there would be a maintenance
> burden, but giving one example of a library that works is meaningful.
> And, since GCC is still a GNU project, mentioning the status of GNU libc
> doesn't seem that arbitrary.

Can you propose a change along these lines?  I think it does make
sense, both to be more clear on what may be a (non-)issue and to
refer to GNU libc as a reference implementation where that makes
sense.

Gerald

Re: C99 Status - inttypes.h

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

Quoting Gerald Pfeifer <gerald@pfeifer.com>:

> On Fri, 22 Jul 2011, Joern Rennecke wrote:
>> I agree that trying to track every library there would be a maintenance
>> burden, but giving one example of a library that works is meaningful.
>> And, since GCC is still a GNU project, mentioning the status of GNU libc
>> doesn't seem that arbitrary.
>
> Can you propose a change along these lines?  I think it does make
> sense, both to be more clear on what may be a (non-)issue and to
> refer to GNU libc as a reference implementation where that makes
> sense.

Attached.


[-- Attachment #2: c99-supp-doc-lib --]
[-- Type: text/plain, Size: 1405 bytes --]

Index: c99status.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v
retrieving revision 1.57
diff -p -r1.57 c99status.html
*** c99status.html	18 Mar 2011 17:47:35 -0000	1.57
--- c99status.html	25 Sep 2011 12:15:59 -0000
*************** href="http://www.open-std.org/jtc1/sc22/
*** 13,19 ****
  (E), ISO/IEC 9899:1999/Cor.2:2004 (E) and ISO/IEC 9899:1999/Cor.3:2007
  (E)).</p>
  
! <p>Where "Library Issue" is listed in conjunction with some other
  status, this means that some compiler support is needed for the
  library support, or desirable in conjunction with it.  Note that the
  headers required of conforming freestanding implementations (clause 4
--- 13,23 ----
  (E), ISO/IEC 9899:1999/Cor.2:2004 (E) and ISO/IEC 9899:1999/Cor.3:2007
  (E)).</p>
  
! <p>"Library Issue" means that support may or may not be available depending
! on the C library used; for example, the GNU C library supports all C99
! features, provided _ISOC99_SOURCE and/or _GNU_SOURCE is defined in the
! source code or with a -D preprocessor flag.
! Where "Library Issue" is listed in conjunction with some other
  status, this means that some compiler support is needed for the
  library support, or desirable in conjunction with it.  Note that the
  headers required of conforming freestanding implementations (clause 4

Re: C99 Status - inttypes.h

[Joseph S. Myers]

On Sun, 25 Sep 2011, Joern Rennecke wrote:

> ! <p>"Library Issue" means that support may or may not be available depending
> ! on the C library used; for example, the GNU C library supports all C99
> ! features, provided _ISOC99_SOURCE and/or _GNU_SOURCE is defined in the
> ! source code or with a -D preprocessor flag.

Referring to these feature test macros is not a good idea, the normal way 
for them to be defined is internally by libc in response to 
__STDC_VERSION__ defined by the compiler.

(There are various miscellaneous conformance issues in glibc as well.  
Apart from what's mentioned in libc's CONFORMANCE file:

* Macros that should be usable in #if defined as enums.

* <math.h> and <complex.h> do not declare long double functions when same 
  representation as double (fixed in EGLIBC by a patch of Jakub's that was 
  ignored for FSF glibc).

* Mathematical function error handling generally a mess: GLIBC bugs
  3866 3868 5680 6759 6776-6788 6792-6799 6801-6810 6814 (this list of bug 
  numbers may be out of date).

* Mathematical functions broken in non-default rounding modes: GLIBC
  bugs 3976 6869.

* Headers redirect functions to standard versions in some cases where C 
  requires this to work without explicitly including headers (might be 
  fixable with pragma redefine_extname in implicitly included header).

* wmemcmp/wcscmp handling of some wchar_t values (see recent libc-alpha 
  discussion; clearly a C94 and C1X conformance bug, less clearly a C99 
  bug).

* Power Architecture malloc alignment 
  <http://sourceware.org/ml/libc-alpha/2007-11/msg00062.html> (see more 
  recent discussion of this patch in the x32 context).

* Fixes to fenv.h fallback functions were rejected 2011-01-08.

* ARM, MIPS wrongly save/restore fp state in setjmp/longjmp.

I'd welcome details of any other issues people think are C standards 
conformance bugs in glibc.  (I also have some notes of possible issues in 
the soft-fp code and architecture-specific issues in some mathematical 
functions.))

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: C99 Status - inttypes.h

[Gerald Pfeifer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 489 bytes --]

On Sun, 25 Sep 2011, Joern Rennecke wrote:
> Attached.

Thanks, Jörn!

! <p>"Library Issue" means that support may or may not be available depending
! on the C library used; for example, the GNU C library supports all C99

I suggest a full stop isntead of ";" before "for example" and to just
say "defined" without going into the how.

Joseph, how do you suggest to rephrase the note on activation?  
Just -std=c99 as an option to GCC which then triggers the appropriate
#defines?

Gerald

Re: C99 Status - inttypes.h

[Joseph S. Myers]

On Mon, 26 Sep 2011, Gerald Pfeifer wrote:

> Joseph, how do you suggest to rephrase the note on activation?  
> Just -std=c99 as an option to GCC which then triggers the appropriate
> #defines?

Yes.

-- 
Joseph S. Myers
joseph@codesourcery.com