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

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 27, 2013, Torvald Riegel <triegel@redhat.com> wrote:

> On Tue, 2013-11-26 at 18:28 -0200, Alexandre Oliva wrote:

>> There, ân.â, âpl.â, âCf.â, âF.â are all non-English terms used for
>> convenience throughout the dictionary

>> Why should that be a problem for us?

> are we building a dictionary here? No.

What is it that distinguishes our providing definitions for terms people
look up from a dictionary's?

> is space as scarce as in a traditional dictionary? No.

Are you not aware the FSF prints and sell printed copies of GNU manuals?

Anyway...  I'm glad to drop this discussion, since we appear to be
converging on a set of short keywords.

>> >> Exactly!  They want to learn *exactly* what those odd combinations of
>> >> letters mean!  Somehow when it's a function name among other made-up
>> >> terms from C, that's perfectly readable,
>> 
>> > Why do you think those are perfectly readable?
>> 
>> Linguistics: because we're already used to them.

> That we're already used to them, and learned to deal with them, doesn't
> mean at all that they are perfectly readable.

Heh.  I sense some circularity in the reasoning here.  Joseph's (and
your, to a significant extent) argument was that he wanted English words
because they are easier to read.  They are easier to read precisely
because they're familiar, we're already used to them.  Words are
arbitrary combinations of letters; what makes them easier or harder to
read is not any inherent property, it's just that our brains develop
circuits optimized to recognize the patterns we're used to.

So, for us who deal with this every other day, setpwent and cbrt and
wcstok are familiar and easy to read; for a new user who's learning
about C and POSIX and glibc, these are all new and hard to read.

Same goes for dictionaries, mind you.  Once we get used to n. and
adj. and such stuff, it becomes second nature, but try to remember the
first time you opened a dictionary to look a word up.  There is a *lot*
of stuff that we learn to filter out over time so that we can focus on
what we're looking for.  One of my concerns is that, the longer the
portion about safety is at each function, the more threatening it will
seem for a significant portion of our target audience.

> As a counter-example to what you said, you replied to Joseph's
> suggestion of "environment" with, basically "What about 'environment'?".

I proposed a much shorter and just as usual term.  I'm not entirely
happy about those alternate terms I proposed, though; I do think they're
worse overall, however, I'm willing to concede on them for the sake of
general agreement.  If we don't get that, well, I'll likely remain at
the terms that I find more precise (once their definitions are looked
up, and they have to because they're hardly guessable) and denser in
meaning (in that they bring more concepts to mind in a single word).

> That's seems exactly the case of an existing word used as term/keyword,
> yet people will look up what it means.

Unless they can guess what they mean and get in their head an idea about
it that no amount of defining or showing or arguing will change.  Your
assumptions about the meaning of MT-Safe are a perfect example of this
phenomenon ;-(

> It sounded as if you would plan to drop out of the work if we can't get
> unanimous consent for this one.

That's not an option for me.

What I can drop out of is unrelated discussions, and of coming up with
keywords that everyone agrees on; I can complete my work with macros
that expand to something, or to nothing, and let others argue about it
till they come to an agreement.

> Okay.  I see the point, but that opens up more question for me than
> indicating to me that "race" is the best name.

I liked staticbuf better, but I'm not the one who ruled that out.
Anyway, it's just a mnemonic for the concept fully defined elsewhere.
datarace is no better than race in this regard IMHO.

> Also, I suppose programmers would have to guard against the iterator
> problem in the same way that they would guard against any data race?

No, they'd have to refrain from calling the functions altogether,
because they're not safe.

Unless they really want to call them, in which case there *might* be a
way to guard against the races.  It's not always the case that there is,
though.

> I agree on "mem" and "fd" being widely understood, so I thought adding
> "leak" to qualify them a little further would be the right thing to do.

I thought this was ruled out because the combination wouldn't be an
English word.

>> No loss there.  selfdeadlock was AS-only and lockleak was AC-only, so
>> the distinction would remain.  Indeed, I'd probably still use different
>> macros for them, just to make it easier to set them apart mechanically,
>> should we decide to do so at a later time.

> The above was meant as a general comment to all those categories, sorry
> if that wasn't clear.

The response applied to all of them, except the ones singled out in the
following paragraph.  Sorry if I didn't make it clear.

>> The only classes that would actually become indistinguishable would be
>> staticbuf and xguargs, and maybe some or all cases of uunguard.  The
>> more I thought about these, the more I concluded the definitions were
>> mostly hair-splitting; adding sub-notes that indicate what the race is
>> about will make up for any apparent loss.

-- 
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