This is the mail archive of the cygwin-talk mailing list for the cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]