* Re: C99 Status - inttypes.h
2011-07-22 15:38 ` Joern Rennecke
@ 2011-07-22 17:43 ` Paulo J. Matos
2011-07-22 20:12 ` James Dennett
2011-07-23 19:29 ` Weddington, Eric
2011-08-21 19:27 ` Gerald Pfeifer
2 siblings, 1 reply; 18+ messages in thread
From: Paulo J. Matos @ 2011-07-22 17:43 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: C99 Status - inttypes.h
2011-07-22 17:43 ` Paulo J. Matos
@ 2011-07-22 20:12 ` James Dennett
0 siblings, 0 replies; 18+ messages in thread
From: James Dennett @ 2011-07-22 20:12 UTC (permalink / raw)
To: Paulo J. Matos; +Cc: gcc
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: C99 Status - inttypes.h
2011-07-22 15:38 ` Joern Rennecke
2011-07-22 17:43 ` Paulo J. Matos
@ 2011-07-23 19:29 ` Weddington, Eric
2011-07-23 21:10 ` Eric Botcazou
2011-08-21 19:27 ` Gerald Pfeifer
2 siblings, 1 reply; 18+ messages in thread
From: Weddington, Eric @ 2011-07-23 19:29 UTC (permalink / raw)
To: Joern Rennecke, Paulo J. Matos; +Cc: gcc
> -----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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: C99 Status - inttypes.h
2011-07-23 19:29 ` Weddington, Eric
@ 2011-07-23 21:10 ` Eric Botcazou
2011-07-23 22:47 ` Weddington, Eric
0 siblings, 1 reply; 18+ messages in thread
From: Eric Botcazou @ 2011-07-23 21:10 UTC (permalink / raw)
To: Weddington, Eric; +Cc: gcc, Joern Rennecke, Paulo J. Matos
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: C99 Status - inttypes.h
2011-07-23 21:10 ` Eric Botcazou
@ 2011-07-23 22:47 ` Weddington, Eric
0 siblings, 0 replies; 18+ messages in thread
From: Weddington, Eric @ 2011-07-23 22:47 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc, Joern Rennecke, Paulo J. Matos
> -----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. :-)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: C99 Status - inttypes.h
2011-07-22 15:38 ` Joern Rennecke
2011-07-22 17:43 ` Paulo J. Matos
2011-07-23 19:29 ` Weddington, Eric
@ 2011-08-21 19:27 ` Gerald Pfeifer
2011-09-25 13:00 ` Joern Rennecke
2 siblings, 1 reply; 18+ messages in thread
From: Gerald Pfeifer @ 2011-08-21 19:27 UTC (permalink / raw)
To: Joern Rennecke; +Cc: Paulo J. Matos, gcc
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: C99 Status - inttypes.h
2011-08-21 19:27 ` Gerald Pfeifer
@ 2011-09-25 13:00 ` Joern Rennecke
2011-09-25 22:49 ` Joseph S. Myers
2011-09-25 22:53 ` Gerald Pfeifer
0 siblings, 2 replies; 18+ messages in thread
From: Joern Rennecke @ 2011-09-25 13:00 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Paulo J. Matos, gcc
[-- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: C99 Status - inttypes.h
2011-09-25 13:00 ` Joern Rennecke
@ 2011-09-25 22:49 ` Joseph S. Myers
2011-09-25 22:53 ` Gerald Pfeifer
1 sibling, 0 replies; 18+ messages in thread
From: Joseph S. Myers @ 2011-09-25 22:49 UTC (permalink / raw)
To: Joern Rennecke; +Cc: Gerald Pfeifer, Paulo J. Matos, gcc
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: C99 Status - inttypes.h
2011-09-25 13:00 ` Joern Rennecke
2011-09-25 22:49 ` Joseph S. Myers
@ 2011-09-25 22:53 ` Gerald Pfeifer
2011-09-26 7:11 ` Joseph S. Myers
1 sibling, 1 reply; 18+ messages in thread
From: Gerald Pfeifer @ 2011-09-25 22:53 UTC (permalink / raw)
To: Joern Rennecke, Joseph S. Myers; +Cc: Paulo J. Matos, gcc
[-- 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
^ permalink raw reply [flat|nested] 18+ messages in thread