This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: test-netdb.c


> Roland McGrath <roland@frob.com> writes:
> 
> > The draft 7 Open Group spec seems to say that gethostname should truncate
> > the result and return zero when the given buffer length is too short.
> 
> I agree that this is awful.  It's another compromise API.

Such is life.  This is certainly one of the most minor annoyances among
such crocks we must live with.

> > I don't have a problem with that, but it is an incompatible change
> > and could break programs that expect the ENAMETOOLONG behavior.
> 
> What's the alternative?  Keeping the documented behavior means
> stretching the wording of the specification.  

I'm not sure you can call it stretching.  I think we have to admit that the
current documented GNU behavior violates this new specification, and just
move on to the question of whether or not we care.

> It more useful and I don't expect it to cause problems in real
> applications.  If the application is testing the return value it#s good,
> it can react.  If it's not testing the return value it might use a
> truncated and potentially unterminated string.

I am not quite sure what conclusion you are arguing for here.

I like the ENAMETOOLONG behavior, and it has been consistent existing
GNU(/Linux) practice for many years (not that anyone has noticed :-).

OTOH, I would not have any great objection to changing our implementations
and documentation to match the new Open Group spec.  However, since it is a
draft spec, and some libc people (including you) are named as participants
in the process that produced it, perhaps we can still get the spec changed;
I don't know.
 
Finally, I am bit confused by your recent linux/alpha/gethostname.c change.
You've implemented the documented GNU behavior (which I had previously
gotten the impression you were arguing against)--but used EOVERFLOW instead
of ENAMETOOLONG.  One can argue amount the most appropriately-named errno
code for this, but the reason to implement the GNU behavior is for
compatibility with GNU practice and documentation and those use
ENAMETOOLONG.  (In incidental defense of the perhaps inferior choice of
errno code originally made for the GNU behavior, no system had EOVERFLOW at
the time and of logical choices to select from existing codes ENAMETOOLONG
seemed better than E2BIG or ERANGE.)

I think it's now the case that all implementations in use in libc are
consistent with the documentation except for this new linux/alpha one.
Whatever the behavior, all should be consistent.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]