Re: if_flags

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> To cite the example at readiest hand in this thread: are the API
>> fields bearing interface flags (eg, struct ifreq .ifr_flags) defined
>> to be unsigned shorts, or are they defined to be some unsigned
>> integral type no larger than unsigned long int, or what?
> They are exactly whatever the 4.4 if.h file says they are.  That's
> the spec.  Not some other type that might be kind of similar to the
> one actually used in the struct definition.  But that exact one.
> Change from short to unsigned short and you've altered the API.

Then the API consists of the source code *with that specification*.

The source code alone is not enough; it does not define whether that
"short" is "this field is defined to have this type" or "this field is
defined to have certain characteristics, and this type is one of the
possibilities".  The example I gave was an instance of this: if I see
"unsigned short if_flags;", that could have resulted from either of the
specs I cited (amogn others), and without additional information I, the
person reading the code to deduce the API, have no way to tell which.

A well-designed API often has things which are _not_ specified (with,
of course, clearly defined boundaries).  The "unsigned integral type
not larger than unsigned long" example is the kind of thing I mean.

>> And this is not a question that can be answered by inspecting
>> sources - unless there's a comment lurking somewhere that talks
>> about it,
> You're assuming that a specification must be written in English.

Actually, I'm not.  I'm just pointing out that C code, by itself, is
not a good spec; it needs some additional other language (probably a
natural language) to supplement it, for reasons outlined above.  An
English spec that provided no more information than the C code ("the
ifr_flags is implemented as unsigned short") would be as bad a spec as
the code itself ("unsigned short ifr_flags") is.

> If anything [the code] is likely to be more precise [than a
> natural-language spec],

Yes, except that it's an implementation, not a spec.  Good specs
constrain the implementation in some respects and leave it latitude in
others, but looking at just an implementation does not give any
indication of how much latitude is permitted.  (Looking at multiple
disparate implementations can, under the assumption that they all
conform, but that's not what's under discussion here.)

> Or it may be that you're assuming that it wasn't necessarily intended
> to be,a nd perhapd doesn't need to be, as precise as it is,

Well, of course.  If the spec were as precise as you're making it out
to be, there would be exactly one possible implementation - the spec
one - and never any change (for example, all implementations would
forever be required to reject anything the reference implementation
rejects, in the same way; this would make it impossible to, for
example, add new socket options).

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B