nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] GCC 8 pre-releases have escaped...


From: Ralph Corderoy
Subject: Re: [Nmh-workers] GCC 8 pre-releases have escaped...
Date: Wed, 07 Feb 2018 20:33:53 +0000

Hi Ken,

> > Yes, I like asprintf(), but it's not POSIX.  snprintf(NULL, 0, fmt,
> > ...) is POSIX and returns the strlen() of what would have been
> > written, allowing a second call to do the work, again, for real this
> > time.
>
> A quick glance suggests to me that even while asprintf() is not part
> of POSIX, it is on *BSD systems, newer versions of MacOS X, and is in
> glibc.  That sounds like pretty good coverage to me.

True, but it's often not the function we want as, you say, it allocates
afresh each time.

> I'd personally be willing to live with the inefficiency of a simple
> {v}asprintf() implementation that just called {v}snprintf() with a
> size of 0 to get the real size and then called it again with a
> correctly-allocated buffer.

Yes, that would be a way to implement asprintf() where it was missing.

> > We could avoid the double effort on most occasions by tracking the
> > size of the existing allocation and only realloc() when it's not big
> > enough.  vsnprintf(3) exists so our function can pass on the va_list
> > to it.
>
> My reading of asprintf() is that it always allocates a new buffer,
> even if the pointer you pass in is already allocated.

And that's bad when you're in a loop wanting to snprintf() to a local
char[] you hope is big enough, use the result, and trample it on the
next iteration.  asprintf() adds NĂ—(malloc+free).  What I suggested is a
few realloc()s as the previous one is occasionally found lacking.  If
current size is 256 and 300 is needed then 512 is claimed.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]