Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000782 [1003.1(2013)/Issue7+TC1] Base Definitions and Headers Editorial Clarification Requested 2013-10-31 22:03 2019-06-10 08:55
Reporter nsz View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Szabolcs Nagy
Organization musl libc
User Reference
Section complex.h
Page Number -
Line Number -
Interp Status ---
Final Accepted Text Note: 0002072
Summary 0000782: complex.h reserved identifiers should be normative
Description ISO C lists reserved identifiers for complex.h in its
future library directions section.

The complex.h description in XBD does not specify these
identifiers as reserved, they are only mentioned in the
future directions section which is informative only.
The reserved identifier table in XSH does not list them
Desired Action list the following identifiers as reserved in normative text
(with f and l suffix as well):

 cerf, cexpm1, clog2,
 cerfc, clog10, clgamma,
 cexp2, clog1p, ctgamma,
Tags tc2-2008
Attached Files

- Relationships

-  Notes
geoffclare (manager)
2013-12-12 17:27
edited on: 2013-12-13 17:09

The table on pages 479 to 480 already reserves those symbols as
identifiers with external linkage (and is normative).
Update: as discussed on the reflector, this is not sufficient.

geoffclare (manager)
2013-12-13 17:08

On page 476 line 16146 add a new paragraph:

    Implementations may also add symbols to the <complex.h> header
    with the following complete names or the same names suffixed with
    f or l:
        cerf    cexpm1   clog2
        cerfc   clog10   clgamma
        cexp2   clog1p   ctgamma
shware_systems (reporter)
2013-12-14 01:51

The C standard reserves those as function names not as symbols or generic identifiers, which C only allows to be defined at file scope, as are all the other identifiers in the table on page 479. The main implied side effect I see of being in that table is it ensures they get implemented in a way suitable for inclusion in a standard library, not as macro only or inline code expansions. As the header FD section includes the () indicating interface or macro is the intended usage, plus requiring it to be external, I construe this as POSIX implicitly not allowing static also as a secondary effect. There's nothing I see overriding the deferral to C otherwise, it's just reworded a bit to be compatible with the description of the table they are reserved in. It doesn't block some implementation from using those identifiers differently, or an application, they just won't be conforming. Am I missing something?

The tables prior rosterize constant or object identifier reservations, not interface identifers, but that isn't all that clear, nor does Item 3. on 478 say anything about the table being interfaces only. There may be a few exceptions but none stand out in that respect. I can see Item 3. being modified to be 'interface identifiers', not add to 476, to keep that distinction. Splitting the table by library wouldn't hurt either to accent that. If those identifiers do get added to <complex.h> by the C standard in a way that differs from how their FD is may be a future issue, but I think the intent is clear enough otherwise. Using 'identifiers' to refer to #define symbols and object and interface names generically helps the text be less wordy, so I don't see adding more than that one qualifier to disambiguate things being warranted.

- Issue History
Date Modified Username Field Change
2013-10-31 22:03 nsz New Issue
2013-10-31 22:03 nsz Name => Szabolcs Nagy
2013-10-31 22:03 nsz Organization => musl libc
2013-10-31 22:03 nsz Section => complex.h
2013-10-31 22:03 nsz Page Number => -
2013-10-31 22:03 nsz Line Number => -
2013-12-12 17:27 geoffclare Interp Status => ---
2013-12-12 17:27 geoffclare Note Added: 0002071
2013-12-12 17:27 geoffclare Status New => Closed
2013-12-12 17:27 geoffclare Resolution Open => Rejected
2013-12-13 17:08 geoffclare Note Added: 0002072
2013-12-13 17:08 geoffclare Status Closed => Under Review
2013-12-13 17:08 geoffclare Resolution Rejected => Reopened
2013-12-13 17:09 geoffclare Note Edited: 0002071
2013-12-14 01:51 shware_systems Note Added: 0002074
2013-12-19 16:13 geoffclare Final Accepted Text => Note: 0002072
2013-12-19 16:13 geoffclare Status Under Review => Resolved
2013-12-19 16:13 geoffclare Resolution Reopened => Accepted As Marked
2013-12-19 16:13 geoffclare Tag Attached: tc2-2008
2019-06-10 08:55 agadmin Status Resolved => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker