[fetchmail-devel] Re: r3995 - trunk

[Graham W. <gr...@mk...>]

On Fri, Nov 12, 2004 at 11:54:51PM +0100, Matthias Andree wrote:
> Graham Wilson <gr...@mk...> writes:
> > Why do we want it as a separate project?
> 
> 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 wouldn't think there would need to be much updating.
I'm more concerned with adding a whole other project into the fetchmail
tarball.

> > I would have gone with a single file implementation of snprintf instead
> > of using the whole Trio. I don't see why we need to add 54 files when we
> > could just add one. For example, mutt is known to have a good snprintf
> > implmentation.
> 
> 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.

> It's one of the hordes of the Patrick Powell snprintf.c derivates, and
> as such, one that's both incomplete and pretty broken - it uses
> va_arg(args, short int) which is outright nonsense given the promotion
> rules, and it doesn't get return values right as documented.

Well, I thought that was the case. I'm fine not using though if you
don't think the code is good.

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.

On the other hand, the source doesn't seem to be the derived from
Powell's implementation and the return semantics seem correct. The code
is also distributed in tarball form, so it seems updates would be easy
to track (though there hasn't been a release since late 2000 it seems).

-- 
gram