Re: Shortcomings in Win32 API docs
- From: "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx>
- Date: Fri, 13 Oct 2006 21:05:00 -0700
Apparently, FindFirstFile is just filling the fields in a structure provided
by the caller. FtpFindFirstFile is simulating this behavior, while possibly
creating its own copy of structure, and then copying it to the one provided
by a caller. Either way is valid.
<news@xxxxxxxxxxxxxxx> wrote in message
news:1160728541.414059.75730@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Alexander Grigoriev wrote:
An API function might just do an assignment on the structure, which is
equivalent of memcpy(src, dst, sizeof (WIN32_FIND_DATA)), with the size
being 320.
True. I guess we should be grateful that very few API functions return
structures that way! Although FtpFindFirstFile (and I presume
InternetFindNextFile) do write the full 'padded' 320 bytes of
WIN32_FIND_DATA, FindFirstFile and FindNextFile do not.
I would be interested to know just what languages (other than C and its
derivatives) do natively support structure padding in a way compatible
with what the API expects. Can anybody tell me?
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
.
- Follow-Ups:
- References:
- Shortcomings in Win32 API docs
- From: news
- Re: Shortcomings in Win32 API docs
- From: Alexander Grigoriev
- Re: Shortcomings in Win32 API docs
- From: news
- Re: Shortcomings in Win32 API docs
- From: Alexander Grigoriev
- Re: Shortcomings in Win32 API docs
- From: news
- Shortcomings in Win32 API docs
- Prev by Date: Re: How will PatchGuard change kernel programming?
- Next by Date: Re: How will PatchGuard change kernel programming?
- Previous by thread: Re: Shortcomings in Win32 API docs
- Next by thread: Re: Shortcomings in Win32 API docs
- Index(es):