christos@zoulas.com (Christos Zoulas) writes:

> On May 21,  9:52am, Klaus@security.kpnqwest.com (Klaus@security.kpnqwest.com, Klein <kleink@uni-tri) wrote:
> -- Subject: Re: getnameinfo type incompatibility
> 
> | The motivation for going this route is that nothing about this type is
> | machine-dependent, and a further disadvantage of the current
> | <machine/ansi.h> model is the inability to use the private
> | (namespace-clean) type macro definition once it's been used to typedef
> | the public name, which is often desirable for private interfaces in
> | public headers or ambiguities in a standard concernding the
> | namespace used by a header.
> 
> I have not read the standard, but this looks suspiciously similar to
> size_t, so it might be allowed to have it either unsigned long or unsigned
> int. Private interfaces whould be if-def'ed out so they are not visible
> in user space. As far as avoiding ambiguities in the standard, I have
> no solution.

(Private interface were just meant as an example to illustrate the issue.)

As for a bit of history on socklen_t itself, initially size_t was used
in the 1003.1g socket interfaces definition but then several vendors
expressed their concern about an incompatible ABI change on LP64
platforms, and the compromise became socklen_t.

> | I do want to use this model (among other things) to make visible off_t
> | in <stdio.h> in a non-invasive way; I think you'll agree with me that
> | adding a _BSD_OFF_T_ in <machine/ansi.h> is not the way to address
> | this issue.
> 
> Has long long been sanctioned by ansi now?

It's now part of ISO C99.

> I still like to do things in one way and one place...

<machine/ansi.h> currently is one way and many places, I'd say. :-)
Though ultimatately I agree with the desire for One Place, there are
still some dependencies on the MD definitions to be considered,
i.e. GCC target macros.


- Klaus