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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: I: [PATCH] asprintf error handling fix


Ulrich Drepper <drepper@redhat.com> writes:

> James Antill <james@and.org> writes:
> 
> >  This isn't true, I was under the impression that the return value
> > from asprintf() would be the same as that from snprintf(). Thus the
> > few times I've used asprintf() I've just done...
> 
> This only means your program is broken.

 I never said it wasn't, and I've fixed a bunch of code I still
maintain before I wrote the email. You snipped the relevant bit of
text.

 Dmitry basically said:

I'm talking about [fixing it for] already written software which rely
on zeroing result_ptr.

 You said:

There is no such software using glibc.

 I said:

This isn't true, because I've written software like that.

...and although it's a mistake it isn't obvious that the asprintf()
return code would be drastically different to the snprintf() return
code[1] and I don't see why other C programers using this interface
will fair much better than I did (remember that I _did_ read the
documentation, just not the info documentation).

> >  And even if you still consider it incompatible with older glibcs
> > there is ample precedent for changing functions to do the right thing
> > (snprintf() had a much bigger API change, for example).
> 
> This is completely irrelevant.  Bug fixes are one thing, arbitrary
> semantic changes are another.

 So now "arbitrary" means changing a non standard function to be more
inline with what a programer using it would expect it to do. Not only
that but from what Dimitry has said it's also what other
implementations do.

 That's a very different definition than the one in my dictionary.

> > [1] I can't think of a std. function that has an int return value and
> > also returns a ptr value through a parameter atm.
> 
> The situation is the same as with errno.  Unless the return value of a
> function says so nobody must look at it's value.

 Again you've removed relevant context. You said:

  The interface is completely in line with other interfaces which
behave the same.

...and I say that's completely untrue, asprintf() doesn't have
anything to do with errno like interfaces and has everything to do
with *printf() like interfaces. And all of the later never return a
value < 0.

> There will be no change.  Stop complaining and fix your code.

[1] Also note that the info documentation for asprintf() doesn't match
reality, as it says the return value will be either < 0 or the number
of characters allocated for the buffer. This isn't true, the value is
the same as from snprintf() except in the case of allocation failure
(well unless you aren't allocating space for the terminating
character).
 So you need to change something.

-- 
# James Antill -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null


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