Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)

2010-11-10 Thread Alexandre Julliard
Eric Pouech eric.pou...@orange.fr writes:

 msvcr90 doesn't set msvcrt's errno in case of error, while msvcrt does
 Hence the wrappers inside msvcr90 around _itoa_s and _itow_s calls.

Do you have an app that depends on this?

-- 
Alexandre Julliard
julli...@winehq.org




Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)

2010-11-10 Thread Eric Pouech

Le 10/11/2010 17:34, Alexandre Julliard a écrit :

Eric Pouecheric.pou...@orange.fr  writes:


msvcr90 doesn't set msvcrt's errno in case of error, while msvcrt does
Hence the wrappers inside msvcr90 around _itoa_s and _itow_s calls.

Do you have an app that depends on this?


no, just the current tests that fail
A+

--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the 
ingenuity of a complete idiot. (Douglas Adams)





Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)

2010-11-10 Thread Alexandre Julliard
Eric Pouech eric.pou...@orange.fr writes:

 Le 10/11/2010 17:34, Alexandre Julliard a écrit :
 Eric Pouecheric.pou...@orange.fr  writes:

 msvcr90 doesn't set msvcrt's errno in case of error, while msvcrt does
 Hence the wrappers inside msvcr90 around _itoa_s and _itow_s calls.
 Do you have an app that depends on this?

 no, just the current tests that fail

Then I'd say don't bother replicating that for now. Setting errno when
getting invalid parameters seems quite reasonable.

-- 
Alexandre Julliard
julli...@winehq.org




Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)

2010-11-10 Thread Eric Pouech

Le 10/11/2010 22:32, Alexandre Julliard a écrit :

Eric Pouecheric.pou...@orange.fr  writes:


Le 10/11/2010 17:34, Alexandre Julliard a écrit :

Eric Pouecheric.pou...@orange.fr   writes:


msvcr90 doesn't set msvcrt's errno in case of error, while msvcrt does
Hence the wrappers inside msvcr90 around _itoa_s and _itow_s calls.

Do you have an app that depends on this?


no, just the current tests that fail

Then I'd say don't bother replicating that for now. Setting errno when
getting invalid parameters seems quite reasonable.


so we stop testing that we didn't set errno in msvcrN0 for _s functions?
A+

--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the 
ingenuity of a complete idiot. (Douglas Adams)





Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)

2010-11-10 Thread Alexandre Julliard
Eric Pouech eric.pou...@orange.fr writes:

 Le 10/11/2010 22:32, Alexandre Julliard a écrit :
 Eric Pouecheric.pou...@orange.fr  writes:

 Le 10/11/2010 17:34, Alexandre Julliard a écrit :
 Eric Pouecheric.pou...@orange.fr   writes:

 msvcr90 doesn't set msvcrt's errno in case of error, while msvcrt does
 Hence the wrappers inside msvcr90 around _itoa_s and _itow_s calls.
 Do you have an app that depends on this?

 no, just the current tests that fail
 Then I'd say don't bother replicating that for now. Setting errno when
 getting invalid parameters seems quite reasonable.

 so we stop testing that we didn't set errno in msvcrN0 for _s functions?

Yes. In general, we test last error when it's expected to be set, but we
shouldn't test it when a function doesn't set it, because depending on
the call stack it may or may not be changed by sub-functions. errno can
be treated the same way.

-- 
Alexandre Julliard
julli...@winehq.org




Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)

2010-11-09 Thread Eric Pouech
to sum up the recent discrepencies between msvcrt and msvcrN0 Dlls:
- msvcrt doesn't raise exception on _s functions while msvcrN0 does
- (likely) in _s functions returning an errno_t value, msvcrt does set errno
to the returned value, while msvcrN0 doesn't change the errno value (tested
on _itoa_s and wcsncat_s)

I wonder if should challenge the current scheme of forwarding all APIs from
msvcrN0 to msvcrt (and writing wrappers in msvcr90 to cope with the various
discrepencies)

we could let msvcrt behave differently when loaded from our msvcrN0 DLLs
than when loaded standalone, and factorize the discrepencies within msvcrt
itself

comments welcome
A+
-- 
Eric Pouech