Re: Consensus on MT-, AS- and AC-Safety docs.

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 21, 2013, "Joseph S. Myers" <joseph@codesourcery.com> wrote:

> On Thu, 21 Nov 2013, Alexandre Oliva wrote:
>> One is that nearly all functions may modify errno in certain
>> circumstances.  This means nearly every function would get a note, so it
>> might end up becoming background noise.

> You could then put something in the general definition of what AS-Safe 
> means.

Hey, that could cover the fpresenv caveat too!

> And set all registers to initial values when the handler is called, rather 
> than calling it with any registers in the state they were at the time the 
> thread was interrupted?

I don't think I looked into that, but it's been a while.  My memory
isn't as good as I (don't :-) remember it was before ;-)

>> Should I bring simfpu back, named, hmm...  fpresenv?  And then add a

> I prefer longer, more readable names (e.g. floating-point-environment).

But that's meaningless.  Well, yeah, I understand
âfloating-point-environmentâ, but what about it? :-)
does-not-preserve-the-floating-point-environment and
may-not-preserve-the-floating-point-environment-on-cancellation are
-EWAYTOOVERBOSETOBEUSEFULASKEYWORDS to me ;-)

We actually have good, settled precedent in using non-English keywords
in error codes that may be stored in errno.

>> Eeek.  I don't recall auditing functions that do this.  I audited the
>> funtions in arith.texi a long time ago, and those in math.texi more
>> recently but not that recently, so I may have forgotten all about it.
>> But I'm now concerned I may have missed these behaviors entirely.  Are
>> they introduced by means of mazes of includes or macros that I may have
>> got lost in?  Are functions that do this documented in the manual?  (if
>> they aren't, and they aren't dependendencies of those that are, I'm
>> blind to them in this project ;-)

> See for example math/w_pow.c - the pow function is documented in 
> math.texi.  And sysdeps/ieee754/k_standard.c for what's covered by the 
> __kernel_standard calls (which includes writing to streams).

Thanks, now that I can relate what you were writing with my
recollections of reviewing that code, I remember having looked at
kernel_standard and its callers; it all looks familiar, but I don't seem
to have taken note of the reasons why I didn't add notes about the
potential of stream uses et al in there.  If I had to guess (and I do
:-) I'd say it was because I remember that this was all deprecated (I
vaguely recall reading some email about that not too long ago), or I
mistook _LIB_VERSION as a constant and from that misconcluded the code
in question would have been optimized away or never executed (I can't
rule out this possibility).

Anyway...  What now?  Should the manual even mention this caveat when it
doesn't seem to document the deprecated feature at all?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer