0000782: complex.h reserved identifiers should be normative

Notes
(0002071) 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.

(0002072) 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

(0002074) 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

Relationships

Aardvark Mark IV