Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000713 [1003.1(2013)/Issue7+TC1] System Interfaces Editorial Omission 2013-06-18 00:00 2021-12-13 14:58
Reporter nsz View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Szabolcs Nagy
Organization musl
User Reference
Section remquo
Page Number
Line Number
Interp Status ---
Final Accepted Text See Note: 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
Attached Files

- Relationships

-  Notes
(0005312)
nick (manager)
2021-04-14 15:01

 If the standard says nothing about this case (which it doesn't), then the value is implicitly unspecified.
(0005314)
kre (reporter)
2021-04-14 15:28

 Re Note: 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.
(0005317)
geoffclare (manager)
2021-04-15 09:08

 Re: Note: 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.
(0005319)
kre (reporter)
2021-04-15 19:58
edited on: 2021-04-15 19:59

 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.
(0005379)
nick (manager)
2021-06-16 00:40

 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
(0005380)
Vincent Lefevre (reporter)
2021-06-16 08:17

 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.
(0005381)
shware_systems (reporter)
2021-06-16 18:25
edited on: 2021-06-16 18:30

 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.
(0005382)
Don Cragun (manager)
2021-06-16 18:27
edited on: 2021-06-16 18:28

 Re Note: 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.
(0005383)
Vincent Lefevre (reporter)
2021-06-16 22:19

 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.
(0005384)
kre (reporter)
2021-06-17 12:30

 Re Note: 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.
(0005526)
nick (manager)
2021-11-18 13:30

 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]
(0005527)
Don Cragun (manager)
2021-11-18 16:17
edited on: 2021-11-18 16:22

 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.

- Issue History
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:23 kre Note Added: 0005313
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:58 kre Note Deleted: 0005313
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 Note: 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

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