This is the mail archive of the
cygwin-talk
mailing list for the cygwin project.
RE: Inconsistent behavior for Win32 executable: starting from bashvs. starting from cmd.exe
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: The Cygwin-Talk Maiming List <cygwin-talk at cygwin dot com>
- Date: Mon, 11 Jul 2005 13:59:45 -0400 (EDT)
- Subject: RE: Inconsistent behavior for Win32 executable: starting from bashvs. starting from cmd.exe
- References: <SERRANOxPoLMOEYzk8T00000495@SERRANO.CAM.ARTIMI.COM>
- Reply-to: The Cygwin-Talk Malingering List <cygwin-talk at cygwin dot com>
- Reply-to: The Cygwin-Talk Malingering List <cygwin-talk at cygwin dot com>
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