PATCH: tools/winegcc/utils.c -- casts

Ferenc Wagner wferi at afavant.elte.hu
Mon Nov 3 05:09:26 CST 2003


"Dimitrie O. Paun" <dpaun at rogers.com> writes:

> On October 30, 2003 07:28 pm, Ferenc Wagner wrote:
>
>>> -        if (n > -1 && n < size) return p;
>>> -     size = min( size*2, n+1 );
>>> +        if (n > -1 && (size_t)n < size) return p;
>>> +     size = min( size*2, (size_t)n+1 );
>>
>> Once at it, could you please explain to me what the hell is
>> going on here (min)?
>
> Well, the way I see it, it's just trying to minimize
> memory usage in a portable manner. Normally, vsnprintf()
> should return the necessary size of the buffer (in n), if
> the current size is too small.

In libc-2.1 and later, yes it should.  According to MSDN
(and pre-2.1 libc docs), it should not.

> Now, the way the code it's written right now will not work
> if vsnprintf() returns -1 for failure.

It does on XP.  The new conformance tests tells it all...
If written correctly.  See below.

> Question is, do we really need to worry about vsnprintf()
> not returning the correct size of the required buffer?

Seems like this is the case under Windows.  Not under any
reasonable modern GNU/Linuxes.  However, writing portable
code is easy: if the returned value exceeds the buffer
length, allocate that much memory and repeat once.  No need
to loop in this case.

By the way, I really managed to screw myself (and my gcc) up
by mixing libc calls into winetests.  After yesterday's cvs
update, it started to behave really strange.  It was sort of
working before (creating temporary files under /tmp), but
after the update it is creating a directory called
"C:\\TEMP\\wctX" under programs/winetests...  It took me
some good time to realise this, and I could not stop
laughing when I finally did.  It is obviously some funny
mixture of libc and msvcrt functions, probably due to
./configure recreating the Makefile...  So I could use some
clarification on this issue.  What I think is:

Normally I use the Unix libc functions.  If I #include
"config.h" #include "wine/port.h" and -lwine_port, I use the
Windows runtime (msvcrt).  By prepending and underscore, I
always get the msvcrt functions.

But what is the truth?  The scanf.c test clearly contradicts
the above theory.  I may be better off using the _names to
avoid this confusion...

Feri.



More information about the wine-devel mailing list