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


On Fri, Dec 07, 2001 at 01:40:58PM +0100, Andreas Jaeger wrote:
> >> > - When either malloc or _IO_vfprintf call fails, _IO_vasprintf returns
> >> >   error code without setting result_ptr to zero.
> >> 
> >> That's nonsense.  The code never did this and there is no reason to
> >> ever do this.
> >
> > I didn't get your point - you are rejecting API extension just because it
> > wasn't here before? Well, a lot of features wasn't here before but will
> > appear in the future. Or maybe you did a feature freeze in glibc?
> 
> You propose an extension?  That wasn't clear from your email.  If you
> like to make such changes, you should communicate it better.  Please
> note that it's always best to separate bug fixes (and that's how this
> email is titled) and enhancements.

OK, thank you for the hint.

> > I'm arguing for this feature because it:
> > + cannot harm or lead to negative effects;
> > + costs nothing;
> > + may help to make software a bit more reliable without additional
> >   programmer and audit efforts;
> > + provides compatibility.
> >
> > I see four pros and no contras so far.
> 
> And the same software will break on older glibc systems or non-glibc
> systems since people depend on this.  People have to check the error

Yes, people writing new software have to check asprintf return code,
to ensure their work will function properly both on old, fresh and
non-glibc systems.

I'm talking about already written software which rely on zeroing
result_ptr.

> code and cannot rely on this behaviour.  It might even make fixing the
> bug (not checking asprintf error) even harder to find the bug because
> it occurs later...

In this case no: former asprintf implementation in bad written program
usually results to free(unitialized_pointer), while suggested feature will
lead to free(0). See the difference?


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.ru/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

Attachment: msg00043/pgp00000.pgp
Description: PGP signature


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