Re: Differences between man-pages and libc manual safety markings

[Alexandre Oliva <aoliva-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Oct 30, 2014, Torvald Riegel <triegel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> On Thu, 2014-10-30 at 16:24 -0200, Alexandre Oliva wrote:
>> >> > The hardware requires synchronizing accesses, and just the mere presence
>> >> > of a data race may lead to undefined behavior of the program.
>> 
>> Sorry, but “undefined behavior” is standardese for “don't do that”.

> It's don't do that for a reason, not just don't do that and you'll be
> fine.

Yup.  But remember, it's users of the standard we implement that are not
supposed to do that.  We can and often do get away with such stuff as
part of the implementation of the standard.  There's a long history of
doing so: remember when we implemented mutexes without standard atomics?
Nowadays, you might look at them and find those implementations
disgusting, and think “how the heck nobody thought of documenting the
reliance of this code on certain memory model properties that no longer
hold?”  The obvious answer is that, back then, such properties were
perfectly normal and they had no idea something else might take over in
the distant future.  The point I'm trying to make is that there's only
so much future-proofness you can put into this sort of documentation.
The most difficult bits to document are not those that are surprising as
of the writing of the docs, but those that are blatantly obvious to
pretty much anyone at that time, but that over time become surprising.
Historians run into lots of walls related with this sort of implicit
knowledge of a time.

> Please try to understand the issue.

I do.  It's very clear to me.  You wanted and hoped me to do a lot of
work that I was not supposed to do, and I didn't do it, in part because
I have little hope of seeing the future as well as you claim to be able
to.

> How is that supposed to work if you haven't documented all the
> assumptions you made (i.e., if ctermid is not just an outlier)?

It is, but if I were to document all the assumptions I made, I'd have to
write several books of assumptions, encoding all the knowledge I've
accumulated about how past and present hardware architectures work, any
one of which might change in future architectures.

> Should I review all the code again?

Sure!  Clearly you're not happy with the annotations and comments I
made, so I don't see another way to go about it.

> you didn't seem interested back then.

There's a huge difference between being interested and being pragmatic
about fulfilling one's assignment from up the management chain, rather
than doing somebody else's work while slowing down one's own.

> You said elsewhere in the thread that you have no other information than
> what's in the manual

... and what we covered in earlier discussions.

> what assumptions you made beyond the contracts of functions

Heh.  It's almost funny that you talk about the contracts of functions,
when you yourself claimed their definitions were not clear enough to
figure out what the precise requirements were.  Please make up your mind
about that point before wasting more my time, will you?

-- 
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 Brasil GNU Toolchain Engineer
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html