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

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

[Dave Korn]

----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....

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

[Igor Pechtchanski]

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).

> > 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.

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

It is.

> 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' ...

Yep...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

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

[Dave Korn]

----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....

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

[Gerrit P. Haase]

Dave Korn wrote:

>   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.

You probably meant a hippo is > or < 2k in *weight*?

Gerrit

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

[Dave Korn]

----Original Message----
>From: Gerrit P. Haase
>Sent: 11 July 2005 22:24

> Dave Korn wrote:
> 
>>   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. 
> 
> You probably meant a hippo is > or < 2k in *weight*?
> 
> Gerrit


  I think it would have to be a very small hippo indeed to be < 2kg in
weight, wouldn't it?  Do they make minihippos now?


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

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

[Gerrit P. Haase]

Dave Korn wrote:

> ----Original Message----
> 
>>From: Gerrit P. Haase
>>Sent: 11 July 2005 22:24
> 
> 
>>Dave Korn wrote:
>>
>>
>>>  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. 
>>
>>You probably meant a hippo is > or < 2k in *weight*?
>>
>>Gerrit
> 
> 
> 
>   I think it would have to be a very small hippo indeed to be < 2kg in
> weight, wouldn't it?  Do they make minihippos now?

Actually I thought "2k" is the abbreviation for "2 kilo"
which is an abbreviation for 2000, unit is whatever fits
best, I suggest "kilogram" in this case.


Gerrit

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

[Dave Korn]

----Original Message----
>From: Gerrit P. Haase
>Sent: 12 July 2005 11:02

> Dave Korn wrote:
> 
>> ----Original Message----
>> 
>>> From: Gerrit P. Haase
>>> Sent: 11 July 2005 22:24
>> 
>> 
>>> Dave Korn wrote:
>>> 
>>> 
>>>>  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.
>>> 
>>> You probably meant a hippo is > or < 2k in *weight*?
>>> 
>>> Gerrit
>> 
>> 
>> 
>>   I think it would have to be a very small hippo indeed to be < 2kg in
>> weight, wouldn't it?  Do they make minihippos now?
> 
> Actually I thought "2k" is the abbreviation for "2 kilo"
> which is an abbreviation for 2000, unit is whatever fits
> best, I suggest "kilogram" in this case.
> 
> 
> Gerrit

  Oh, you said 2k but you meant 2kk, now I see!

  Hang on, isn't a kk an M?


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