RE: Inconsistent behavior for Win32 executable: starting from bash vs. starting from cmd.exe

["Dave Korn" <dave dot korn at artimi dot com>]

----Original Message----
>From: Igor Pechtchanski
>Sent: 11 July 2005 17:10

[Thread TITTTL'd because it's nothing more than a pedantic argument over
nit-picking now!]

> On Mon, 11 Jul 2005, Dave Korn wrote:
> 
>> ----Original Message----
>>> From: Igor Pechtchanski
>>> Sent: 11 July 2005 16:26
>> 
>>> Would
>>> 
>>> UNIVERSAL_NAME_INFO szBuff;
>>> UNIVERSAL_NAME_INFO *puni = &szBuff;
>>> 
>>> work better?  I'm not familiar with UNIVERSAL_NAME_INFO, but the above
>>> assumes it's no larger than 2k in size.
>> 
>>   No it doesn't.  Check cbBuff.
> 
> Yes, it does.  

  No, it doesn't *assume* that it's no larger in size, since it behaves
correctly in either case.  IOW, the above example correctly passes the
correct size limit into the WNet... function and correctly detects and
reports the error code that windows correctly returns to it.

> I'm not saying it'll write over 2k into the struct, I'm
> saying the WNetGetUniversalName call may return a weird error if it's
> unable to completely fill in the struct.

  This is a bog-standard idiom throughout the windows API, there are
millions[*] of functions that take a pointer to a buffer and the size of
that buffer and fill it if they can or report ERROR_MORE_DATA if they can't.
Why on earth would it need a DWORD with the size-of-buffer-space if it
wasn't able to handle differently-sized buffers?  What if
UNIVERSAL_NAME_INFO is one of those structs with a variable amount of
trailing data appended?  How would it ever be possible to retrieve such
structures if you couldn't _rely_ on being able to pass in a too-small
buffer and still get a sane result?

    cheers,
      DaveK

[*] -  That's 'millions' in base-2 notation there, i.e. a multiple of
%1000000, i.e. 'maybe as much as a couple of hundred' ...
-- 
Can't think of a witty .sigline today....