Hi,
Jeremie Courreges-Anglas wrote on Wed, Dec 06, 2017 at 06:55:22PM +0100:
> On Tue, Dec 05 2017, Jan Stary <h...@stare.cz> wrote:
>> All annotated occurences of "errno" in intro(2) are .Va,
>> except this one which is .Dv - is that intended?
>>
>> The others talk about the "varible" errno, this one is
>> an "identifier which expands to an addressable location",
>> whatever that means.
It means that code like
int *errno_addr = &errno;
may make sense in certain situations, even though it is usually not
needed, and i suspect doing something like that will usually be an
indication of poor program design. But it is technically valid.
> FWIW, I think it makes sense to speak about errno as a variable (.Va),
So i committed Jan's diff for now, it clearly improves consistency of
the markup and removes a potential source of doubt.
> but to describe that it is actually a preprocessor #define (.Dv)
> under the hood.
Even though it may be hard to invent a different way of actually
implementing the errno variable correctly, the fact that it technically
is a preprocessor macro right now looks like an implementation detail
to me, and i'm not convinced that it needs to be documented. It
might be possible to convince me otherwise if somebody can explain
good reasons why users ought to be told about it, but i don't feel
like working on documenting that myself.
Yours,
Ingo
>> Index: intro.2
>> ===================================================================
>> RCS file: /cvs/src/lib/libc/sys/intro.2,v
>> retrieving revision 1.65
>> diff -u -p -r1.65 intro.2
>> --- intro.2 5 Sep 2017 03:06:26 -0000 1.65
>> +++ intro.2 5 Dec 2017 22:01:26 -0000
>> @@ -51,7 +51,7 @@ Programs may be restricted to a subset o
>> .\"<more later...>
>> .Sh DIAGNOSTICS
>> Nearly all of the system calls provide an error number via the identifier
>> -.Dv errno ,
>> +.Va errno ,
>> which expands to an addressable location of type
>> .Vt int .
>> The address of
