NetUserGetInfo and unsupported levels

[Aidan Thornton]

Hi,

Is there any particular reason why NetUserGetInfo returns success if 
it's called with a valid but unsupported value for level? This seems to 
cause problems for at least MSYS (part of MinGW), as it assumes this 
means that *bufptr has been set to something valid, when in fact the 
function call hasn't done this, or indeed anything much. (See bug #4488.)

Aidan Thornton

[James Hawkins]

On 4/23/06, Aidan Thornton  wrote:
> Hi,
>
> Is there any particular reason why NetUserGetInfo returns success if
> it's called with a valid but unsupported value for level? This seems to
> cause problems for at least MSYS (part of MinGW), as it assumes this
> means that *bufptr has been set to something valid, when in fact the
> function call hasn't done this, or indeed anything much. (See bug #4488.)

Most stub API in wine return TRUE/success, because many apps just
check that the function succeeds and might not depend on the actual
outcome of the API.

--
James Hawkins

[Aidan Thornton]

James Hawkins wrote:
> On 4/23/06, Aidan Thornton  wrote:
> > Hi,
> >
> > Is there any particular reason why NetUserGetInfo returns success if
> > it's called with a valid but unsupported value for level? This seems to
> > cause problems for at least MSYS (part of MinGW), as it assumes this
> > means that *bufptr has been set to something valid, when in fact the
> > function call hasn't done this, or indeed anything much. (See bug #4488.)
>
> Most stub API in wine return TRUE/success, because many apps just
> check that the function succeeds and might not depend on the actual
> outcome of the API.
>
> --
> James Hawkins

Fair enough. I'm not sure that's sensible in this case though; I'd have 
thought most programs would mostly use NetUserGetInfo level 0 if they 
just wanted to check if it succeeded (e.g. to check if the user 
existed), unless they were doing something really weird.

Besides, in this case even programs that don't do anything with the 
outcome of the API call should at least try and free the buffer it 
allocated, possibly with interesting results (seeing as it didn't 
*actually* allocate one).

Aidan Thornton

(Accidentally sent a copy of this reply to sender only; sorry, haven't 
quite got the hang of this yet.)