dlls/userenv: fixed stubs GetUserProfileDirectoryW/A (2nd try)
Nikolay Sivov
bunglehead at gmail.com
Wed Mar 4 11:44:26 CST 2009
Andreas Rosenberg wrote:
> Nikolay Sivov wrote:
>
>
>> Andreas Rosenberg wrote:
>>
>> + if ( !lpcchSize ) {
>> + SetLastError(ERROR_INVALID_PARAMETER);
>> + return FALSE;
>>
>>
>> + SetLastError(ERROR_MORE_DATA);
>> + }
>> + }
>> + }
>> + else
>> + SetLastError(ERROR_REGISTRY_CORRUPT);
>> + }
>> + else
>> + SetLastError(ERROR_REGISTRY_CORRUPT);
>> return FALSE;
>>
>>
>>
>> All these SetLastError are still potentially wrong since you don't check
>> this error codes in your tests.
>>
>
> Sorry, but I disagree with you opinion.
>
> A conformance test should verify if an API call works like documented.
>
Exactly, included these error codes.
> The MSDN documentation specifies nothing regarding error codes for
> GetUserProfileDirectory.
>
> http://msdn.microsoft.com/en-us/library/bb762280(VS.85).aspx
>
> According to MSDN the error codes are not part of the API documentation:
>
> "The error codes returned by a function are not part of the Windows API
> specification and can vary by operating system or device driver. For this
> reason, we cannot provide the complete list of error codes that can be
> returned by each function."
>
That only means a loss of responsibility of error code part.
Documentation specifies nothing about codes
but a call sets (or not) it, and this should be verified.
> http://msdn.microsoft.com/en-us/library/ms679360(VS.85).aspx
>
> I don't consider it helpful writing a conformance test, for something
> that is not specified. One could simply omit the error codes, but if
> this call should fail an app may log/present a more meaningfull error
> message than without it. If the error codes should be different from
> Windows, this is no problem either (..may vary by operating system..).
>
>
You're wrong: application could easily depend on last error code. A
conformance test should verify documented
behavior and investigate undocumented part of it.
More information about the wine-devel
mailing list