Re: [fetchmail-devel] Re: r3995 - trunk

[Matthias A. <ma...@dt...>]

Graham Wilson <gr...@mk...> writes:

> Matthias Andree:

>> Ripping code out of other software is harder to track WRT updates.
>
> I'm not really concerned as much about updates to an snprintf
> implementation;

I am.

> I wouldn't think there would need to be much updating.

More than 4/5 of the snprintf replacements I've looked at were broken in
one way or another.

> I'm more concerned with adding a whole other project into the fetchmail
> tarball.

We aren't doing that.

>> What is the claim mutt had a "good snprintf" implementation based on?
>
> Probably some unfounded claim that I read somewhere else I suppose. If
> you don't think the implementation is good, I'm fine with going with
> something else.

I think the mutt implementation is too incomplete to be useful for
fetchmail.

> What about the implementation at [1]? The downside is that it doesn't
> support a number of conversion characters (f, e, E, g, G, lc, ls, n),
> none of which we seem to use though. There are a few other small things
> missing which I don't think we use (or will) either.

(from different mail)
> [1] http://www.ijs.si/software/snprintf/

It doesn't support %n$ either, which is needed for internationalized
projects, so it, too, is out of the game. I haven't yet had the time to
look _closely_ at snprintfv.


Brian Candler <B.C...@po...> writes:

> What do other projects do with regard to snprintf or lack of it? How many
> Unix systems lack snprintf these days?

I don't know, but I wouldn't want to break compatibility in a patchlevel
or minot update. If we drop all the cruft,  we need to call it 7.0 - and
we'd instead need to get out 6.2.6 or 6.3.0 soon.  We can change
requirements an drop compatibility cruft for a later major version.

> According to the FreeBSD manpage,
>
>      the snprintf() and vsnprintf()
>      functions conform to ISO/IEC 9899:1999 (`ISO C99'').
>
> Would it be reasonable simply to expect a decent O/S to have these functions
> now? I don't know if SunOS 4.1 has snprintf or not,

It doesn't, but SunOS older than 5.7 (IIRC) isn't supported by the
vendor any more.

> If there is a free-standing external snprintf library, then we could just
> point people at it and tell them to install it first if it's needed.

The replacements I've looked at all assumed to be packaged as integral
part of another application.

-- 
Matthias Andree