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 19:00

> On Mon, 11 Jul 2005, Dave Korn wrote:
> 
>> ----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.
> 
> Ok, semantic quibble.  The WNetGetUniversalName function doesn't assume
> anything.  The posted *code* assumed that UNIVERSAL_NAME_INFO fits in 2k
> (since it didn't allocate more space for it).

  Well, if it's nothing but a semantic quibble, let's be *really*
semantically-quibbly about it:  the posted code **doesn't** assume that
UNIVERSAL_NAME_INFO fits in 2k, it assumes that it *might* - OR MIGHT NOT -
fit into 2k, and REACTS ACCORDINGLY!

  Or to phrase that another way, it "doesn't" make any assumption about the
size of the struct.  It merely assumes that the function will behave as it
is documented to behave.

  It's _your_ assumption that the only proper response would be to allocate
a larger buffer and call the function again, but I inisist that reporting
the return code and leaving it to the user to decide what to do next is
equally correct.

  The only way it could *assume* that the struct fit into 2k would be if it
never bothered to check the return code and went ahead and started to try
reading the data out of the struct regardless.  (In fact, for that to be an
assumption that the struct was < 2k, rather than the more general assumption
that the function could never fail, it would have to check for and report
all other possible error codes, and only deliberately ignore
ERROR_MORE_DATA...)

>>> 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?
> 
> To be fair, MSDN lists lpBufferSize as an [in, out] parameter, so it's set
> to the number of bytes needed for the data.

  And also explicitly mentions that ERROR_MORE_DATA is a possible return.

  And also accepts the buffer pointer as an LPVOID because the buffer
pointer might not even _be_ a UNIVERSAL_NAME_INFO struct, since the function
can return a REMOTE_NAME_INFO as well, if desired.

>> What if UNIVERSAL_NAME_INFO is one of those structs with a variable
>> amount of trailing data appended?
> 
> It is.

  So, strictly speaking, there is no answer to the question "Is it > or < 2k
in size"; the proposition is neither true, nor false, but indeterminate.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....