[FFmpeg-devel] [PATCH] [RFC] avoid _vscnprintf since it exists only since WinXP.
Nicolas George
nicolas.george at normalesup.org
Mon Jul 23 01:01:28 CEST 2012
Le quintidi 5 thermidor, an CCXX, Reimar Döffinger a écrit :
> But I admit that I was curious about the code for a few other reasons
> and I probably should have brought that up from the start.
The basic reason behind the design of the code is this: printf and co are a
complex piece of code from the libc. With so many supported OSes, there will
likely be bogus implementations.
There are two specific points about vsnprintf that I do not want to trust
unconditionally:
- That it will not fail for bizarre reasons (maybe a strange locale set by
the application).
- That the return value when the buffer is too small is accurate.
For the first point, I can not do much, but I can be sure not to loop when
the return value is negative.
For the second point here is my solution:
If I trusted vsnprintf, I could write:
len = vsnprintf(...);
if (the buffer was too small) {
enlarge the buffer to len;
len = vsnprintf(...);
}
and it would work. What I wrote instead is:
while (1) {
len = vsnprintf(...);
if (the buffer was large enough)
break;
enlarge the buffer to len;
}
Clearly, if the result of vsnprintf is accurate is accurate, this
equivalent: on the second run, the buffer is always large enough.
It makes a difference if vsnprintf first tells me it needs 32 bytes, and
when I give it 32 bytes, it realizes it actually needs 33: the loop can
accommodate this inaccuracy.
In fact, even without that concern, I find the looping version nicer,
because of the single cal to vsnprintf.
I hope I made things clear.
I just sent a patch for another win32 fallback implementation. I would like
for people with a real windows build environment to test it actually works
(running fate-bprint should be enough). Thanks in advance.
Regards,
--
Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120723/33c7cd68/attachment.asc>
More information about the ffmpeg-devel
mailing list