A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1647 ====================================================================== Reported By: eblake Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1647 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Eric Blake Organization: Red Hat User Reference: ebb.printf %lc Section: fprintf Page Number: 913 Line Number: 30957 Interp Status: Proposed Final Accepted Text: https://austingroupbugs.net/view.php?id=1647#c6239 ====================================================================== Date Submitted: 2023-03-28 16:32 UTC Last Modified: 2023-06-29 01:47 UTC ====================================================================== Summary: printf("%lc", (wint_t)0) can't output NUL byte ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001643 fprintf %lc: wrong reference to the cur... ======================================================================
---------------------------------------------------------------------- (0006366) hvd (reporter) - 2023-06-29 01:47 https://austingroupbugs.net/view.php?id=1647#c6366 ---------------------------------------------------------------------- > Some historical background: the references to translation phases are not in the current standard on the c99 page. They were added to the c17 page in the Issue 8 drafts as part of the bug 0001294 additions to provide a way to create shared libraries. There was certainly no intention that they would have any effect on how standard functions are required to behave. Agreed, but not in the same way that you intend. Even the c89 utility was specified as "compile standard C programs" and "it will accept source code conforming to the ISO C standard". It has always seemed so obvious to me that if _POSIX_C_SOURCE/_XOPEN_SOURCE is not defined, the requirements of ISO C continue to apply in full, that it did not need to be explicitly stated, and changes to the c17 utility that make it easier to infer this should not be read as a change in requirements, merely as a clarification. As it turns out, there is one other place that does say this is what is intended: the description of CX "Extension to the ISO C standard", first added in SUSv3, but I am quoting from 202x_d3-cb2.1.pdf here. > Extension to the ISO C standard > The functionality described is an extension to the ISO C standard. Application developers may make use of an extension as it is supported on all POSIX.1-202x-conforming systems. With each function or header from the ISO C standard, a statement to the effect that ``any conflict is unintentional’’ is included. That is intended to refer to a direct conflict. POSIX.1-202x acts in part as a profile of the ISO C standard, and it may choose to further constrain behaviors allowed to vary by the ISO C standard. Such limitations and other compatible differences are not considered conflicts, even if a CX mark is missing. The markings are for information only. Where additional semantics apply to a function or header, the material is identified by use of the CX margin legend. This is why POSIX requires _POSIX_C_SOURCE in the first place: when _POSIX_C_SOURCE/_XOPEN_SOURCE is not defined, the requirements of ISO C apply and ISO C does not permit e.g. for <stdio.h> to declare getline(). When _POSIX_C_SOURCE/_XOPEN_SOURCE is defined, however, as far as ISO C is concerned, the behaviour is undefined, and another standard such as POSIX that places otherwise conflicting requirements only when such macros are defined is actually not in conflict. I understand from your comments that your view is that when _POSIX_C_SOURCE/_XOPEN_SOURCE is not defined, rather than deferring to ISO C, the behaviour is undefined (unspecified?) in POSIX. For instance, given $ cat >program.c <<EOF && > #include <stdio.h> > int main(void) { puts("Hello, world!"); } > EOF > c17 -o program program.c && > ./program the output is not required by POSIX to be "Hello, world!". Is that a correct interpretation of your comments? If it is, the whole "Extension to the ISO C standard" is silly: there cannot be even a single program that is both valid under ISO C and valid under POSIX under your interpretation that includes any standard library headers: if _POSIX_C_SOURCE/_XOPEN_SOURCE are defined, the behaviour is undefined under ISO C, if _POSIX_C_SOURCE/_XOPEN_SOURCE are not defined, the behaviour is undefined under POSIX. That does not extend ISO C in any meaningful way. But, actually, this raises another concern: ISO C does not require the use of standard library headers (7.1.4p2). On implementations where wint_t is a typedef for int, the below is a correct (but not strictly conforming) ISO C program: extern int printf(const char * restrict format, ...); int main(void) { printf("%lc\n", 0); } Avoiding the use of standard library headers makes this a POSIX-conforming application even without defining _POSIX_C_SOURCE, so presumably would be required to be accepted by the c17 utility even under your interpretation. This exact same program is required by ISO C17 to output nothing, and by POSIX with the proposed bug resolution to output a null byte. As such, the proposed change makes it impossible to continue to classify POSIX as "a profile of the ISO C standard". Issue History Date Modified Username Field Change ====================================================================== 2023-03-28 16:32 eblake New Issue 2023-03-28 16:32 eblake Name => Eric Blake 2023-03-28 16:32 eblake Organization => Red Hat 2023-03-28 16:32 eblake User Reference => ebb.printf %lc 2023-03-28 16:32 eblake Section => fprintf 2023-03-28 16:32 eblake Page Number => 913 2023-03-28 16:32 eblake Line Number => 30957 2023-03-28 16:32 eblake Interp Status => --- 2023-03-28 16:32 eblake Relationship added child of 0001643 2023-03-28 16:33 eblake Desired Action Updated 2023-03-28 17:02 eblake Desired Action Updated 2023-03-28 17:30 eblake Note Added: 0006237 2023-03-28 17:31 eblake Description Updated 2023-03-28 17:37 eblake Desired Action Updated 2023-03-30 16:33 eblake Note Added: 0006239 2023-03-30 17:14 eblake Tag Attached: tc3-2008 2023-03-30 17:14 eblake Tag Attached: issue8 2023-04-03 15:27 eblake Note Added: 0006246 2023-04-03 15:28 eblake Note Edited: 0006239 2023-04-03 15:28 geoffclare Tag Detached: tc3-2008 2023-04-03 15:31 ajosey Interp Status --- => Pending 2023-04-03 15:31 ajosey Final Accepted Text => https://austingroupbugs.net/view.php?id=1647#c6239 2023-04-03 15:31 ajosey Resolution Open => Accepted As Marked 2023-04-03 15:32 ajosey Status New => Interpretation Required 2023-04-03 16:31 ajosey Note Added: 0006248 2023-04-03 16:31 ajosey Status Interpretation Required => Resolution Proposed 2023-04-03 16:46 hvd Note Added: 0006251 2023-04-03 17:15 ajosey Interp Status Pending => Proposed 2023-04-03 17:15 ajosey Status Resolution Proposed => Interpretation Required 2023-04-20 16:22 geoffclare Relationship replaced related to 0001643 2023-06-23 16:19 geoffclare Note Added: 0006346 2023-06-23 16:45 hvd Note Added: 0006347 2023-06-26 09:25 geoffclare Note Added: 0006349 2023-06-26 09:56 hvd Note Added: 0006350 2023-06-27 08:58 geoffclare Note Added: 0006361 2023-06-27 12:29 geoffclare Note Added: 0006365 2023-06-29 01:47 hvd Note Added: 0006366 ======================================================================
