View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000713 | 1003.1(2013)/Issue7+TC1 | System Interfaces | public | 2013-06-18 00:00 | 2024-06-11 09:02 |
| Reporter | nsz | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Omission |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Szabolcs Nagy | ||||
| Organization | musl | ||||
| User Reference | |||||
| Section | remquo | ||||
| Page Number | |||||
| Line Number | |||||
| Interp Status | --- | ||||
| Final Accepted Text | See 0000713:0005527. | ||||
| Summary | 0000713: in remquo quo should be unspecified when the result is NaN | ||||
| Description | the description of quo in remquo(x,y,quo) is "In the object pointed to by quo, they store a value whose sign is the sign of x/y and whose magnitude is congruent modulo 2^n to the magnitude of the integral quotient of x/y, where n is an implementation-defined integer greater than or equal to 3. If y is zero, the value stored in the object pointed to by quo is unspecified." quo does not seem to be correctly specified when x/y is +-Inf or NaN, only the y==0 special case is handled this may affect ISO C as well | ||||
| Desired Action | add with MX shading that if x is +-Inf or x or y is NaN, *quo is unspecified | ||||
| Tags | c99, tc3-2008 | ||||
|
|
If the standard says nothing about this case (which it doesn't), then the value is implicitly unspecified. |
|
|
Re 0000713:0005312 -- I hate "implicitly unspecified" - there are obviously going to be cases (in general, not just here) where the standard says nothing, because no-one ever thought that there was anything to say (never realised the situation can occur). But where such a case is brought to our attention, we should always be explicit in the standard ("x is unspecified" is explicit) to avoid people trying to read (usually invented) meaning into what is not there. |
|
|
Re: 0000713:0005312 Yes it's implicitly unspecified, but that's the point. This bug is classed as editorial - it is pointing out that the wording is inconsistent in that it calls out one special case as explicitly unspecified and leaves the others as implicitly unspecified. It should either call out all of these cases explicitly or none of them. I think the reason we suggested you should refer this to the C committee is purely as a courtesy in case they want to make an editorial improvement to their wording too. |
|
|
I am about to delete note:5313 as I realise now that that the text I quoted is already in POSIX, but only applies to the return value, not what is stored in *quo (the issue of this bug), So, just ignore that one, for anyone who ever saw it. |
|
|
From WG14 (as yet unofficial position from a member of the floating point subgroup): This is an issue raised by The Open Group via WG14 N2723. There are four cases where remquo() can return a NaN: remquo( NaN, y, &quo) remquo( x, NaN, &quo) remquo( infinity, y, &quo) remquo( x, 0, &quo) Only the last case (0==y) says (7.12.10.3 The remquo functions) that quo's value is unspecified. Seems like an oversite. Note: quo is an int, so cannot hold the value NaN. I suggest that words similar to: If a NaN is returned, the value stored in the object pointed to by quo is unspecified. be added to F.10.7.3 The remquo functions |
|
|
About "the value is implicitly unspecified": AFAIK, when the standard says nothing, the behavior is implicitly undefined rather than some value being implicitly unspecified. This is much worse, because doing the operation on such arguments would be invalid, even if the value stored in &quo is never read. |
|
|
As this discussion is happening because the existing practice does not show a clear consensus on what value they store in &quo when NaN is the function result, I think it is in scope fpr the standard to act as referee and be inventive. To this end, as behavior end users can rely upon, I suggest tbe conforming behavior be, under Return Value: If the function is to return a NaN as result value, signalling or quiet, the value zero (0) shall be stored in &quo. I realize this is arbitrary, could use 1, INT_MIN or INT_MAX too, but until integer NaNs are required to be supported this is the cleanest resolution I see. |
|
|
Re 0000713:0005380: I believe that you will find that the POSIX standards explicitly state when something yields undefined behavior. If the standard does not specify the behavior of some activity, the results are implicitly unspecified. |
|
|
But there is an issue concerning the implementations. If POSIX specifies more than ISO C, this means that C compilers used for the c99 utility would need to have a POSIX C dialect mode. Under Debian at least, c99 is a script that runs the gcc command, but GCC doesn't currently have a POSIX mode: if some code has undefined behavior in ISO C and GCC can detect this, it may consider it as dead code (or deduce some value ranges for variables), yielding incorrect code generation for POSIX C source that assumes unspecified results. |
|
|
Re 0000713:0005381 Don't be absurd, it is not this group's role to invent things (or not unless an invention is absolutely needed, which here, it definitely is not). I'll defer to those who know more about arithmetic functions if anyone cares to correct me, but my suspicion is that when the result here is a NaN, there simply is no quotient, and it makes no sense at all for the application to attempt to examine one. That's why, I'd assume, no-one has ever really been bothered by this issue, other than that what the standard says should be complete(and note that in one case, the standard already says the result is unspecified, it is just that there are other cases that were ignored - by picking a specified required value you would not just be making an editorial correction, you'd be modifying the standard). Further when different implementations do different things is not when we get to invent a solution, it is when we say the results are unspecified, which is clearly the correct thing to do here in any case. The (so far, unless things have changed) informal response from WG14 looks to be exactly what is needed, and the same language should be added here. |
|
|
WG14 has voted in a paper to address this issue. See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2790.htm. To align with this, after applying the alignment with C17 (see 0001302), make the following change: On page 1814 line 58758 section remquo(), add a new paragraph after 58763: [MX]If a NaN is returned, the value stored in the object pointed to by quo is unspecified.[/MX] |
|
|
To align with the WG14 resolution, make the following change: On 2018 edition page 1814 line 58758 section remquo(), add a new paragraph after 58763: If NaN is supported and a NaN is returned, the value stored in the object pointed to by quo is unspecified. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-06-18 00:00 | nsz | New Issue | |
| 2013-06-18 00:00 | nsz | Name | => Szabolcs Nagy |
| 2013-06-18 00:00 | nsz | Organization | => musl |
| 2013-06-18 00:00 | nsz | Section | => remquo |
| 2013-06-20 15:54 | nick | Tag Attached: c99 | |
| 2021-04-14 15:01 | nick | Note Added: 0005312 | |
| 2021-04-14 15:28 | kre | Note Added: 0005314 | |
| 2021-04-15 09:08 | geoffclare | Note Added: 0005317 | |
| 2021-04-15 19:58 | kre | Note Added: 0005319 | |
| 2021-04-15 19:59 | kre | Note Edited: 0005319 | |
| 2021-06-16 00:40 | nick | Note Added: 0005379 | |
| 2021-06-16 08:17 | Vincent Lefevre | Note Added: 0005380 | |
| 2021-06-16 18:25 | shware_systems | Note Added: 0005381 | |
| 2021-06-16 18:27 | Don Cragun | Note Added: 0005382 | |
| 2021-06-16 18:28 | Don Cragun | Note Edited: 0005382 | |
| 2021-06-16 18:30 | shware_systems | Note Edited: 0005381 | |
| 2021-06-16 22:19 | Vincent Lefevre | Note Added: 0005383 | |
| 2021-06-17 12:30 | kre | Note Added: 0005384 | |
| 2021-11-18 13:30 | nick | Note Added: 0005526 | |
| 2021-11-18 16:17 | Don Cragun | Note Added: 0005527 | |
| 2021-11-18 16:20 | Don Cragun | Note Edited: 0005527 | |
| 2021-11-18 16:21 | Don Cragun | Interp Status | => --- |
| 2021-11-18 16:21 | Don Cragun | Final Accepted Text | => See 0000713:0005527. |
| 2021-11-18 16:21 | Don Cragun | Status | New => Resolved |
| 2021-11-18 16:21 | Don Cragun | Resolution | Open => Accepted As Marked |
| 2021-11-18 16:22 | Don Cragun | Tag Attached: tc3-2008 | |
| 2021-11-18 16:22 | Don Cragun | Note Edited: 0005527 | |
| 2021-12-13 14:58 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:02 | agadmin | Status | Applied => Closed |
