Problems post sprintf->snprintf conversion

Alex Kiernan alexk at demon.net
Wed Aug 21 05:07:45 UTC 2002


Alex Kiernan <alexk at demon.net> writes:

> Russ Allbery <rra at stanford.edu> writes:
> 
> > Kiernan, Alex <alexk at demon.net> writes:
> > 
> > > Anyone seeing anything like this in there logs (Solaris 8):
> > 
> > > "Aug 19 00:38:01 mutlu.news.demon.net innd: [ID 903239 news.warning]
> > > kibo.news.demon.net:76 closed seconds 3845 accepted 7769 refused 0 rejected
> > > 57 duplicate 53 accepted size "
> > 
> > > Where the accepted size (and all the following fields) are missing?
> > 
> > > I've looked at the change and it looks entirely reasonable. 
> > 
> > Haven't updated to the new innd yet; I'm hoping to do that this week.  I
> > checked those changes by inspection, I fear, rather than extensive running
> > of the code.
> > 
> > That's a really weird place for it to break the line.  It's 14 characters
> > in, so it shouldn't be a sizeof problem.  If you're on Solaris 8, you'll
> > be using the version that comes with INN; if you run make test, does it
> > pass all its tests?  One of them does test %.0f formats, which are being
> > used here.
> > 
> 
> Yup, the tests succeed (I've only one problem with the tests which I
> must dig into some time - vector-t.c fails 55 and 64 when you turn up
> optimisation on Forte C 6.2).
> 
> I'll try to add in some debugging to get to the bottom of it.
> 

Ah, found the problem.

I'm scared.

The floating point formatting in the snprintf replacement breaks when
you try and print something larger than MAXINT, quietly, in a hard to
debug way :( Given INN uses floats to get around just this problem,
this is really, really scary.

The code does:

  intpart = ufvalue;

where ufvalue is the absolute part of the floating point number.  The
conversion then proceeds based on intpart and fvalue - inpart (for the
fractional part). I can't remember what the standard says such
conversion overflows should do, Sun C seems to give you MAXINT.

I'm not sure I even want to fix this - my problem is that if the code
has that kind of hideous assumption, what others are there in there
waiting to bite?

I'll add in some code to use fconvert if we can find it in configure,
if not I'm tempted to give up during configure.

-- 
Alex Kiernan, Principal Engineer, Development, THUS plc


More information about the inn-workers mailing list