WIN-28: fix POSIX file descriptor numbering assumptions

[Adam Megacz]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> Is a file descriptor on windows really an int, or is it a pointer? If 
> its the latter, I don't think we should cast it to an int because it 
> will break on 64-bit.

Gak, it is in fact a pointer. However, I doubt there will ever be such
a thing as Win64 -- Microsoft is most likely going to use the CLR as
their 64-bit ABI. Still, just plain Wrong for me to make casts like
that.


> I recall seeing a patch from Jeff a long time ago to fix FileDescriptor 
> to be more portable and not make the POSIX file-descriptor-is-an-int 
> assumption, but it never got checked in.

Tom Tromey wrote:
> As I recall it used a RawData to represent the file descriptor.
> I think we should resurrect that.

The half-working mingw setup I inherited from Jeff had this change,
although I don't think a diff-and-patch would be the best way to fold
it back in; the structure of natFileDescriptor seems to have changed
too much.

I'll write up a revised patch to use RawData as well as the file
descriptor numbering fixes.

I assume I should _Jv_Malloc(sizeof(file_descriptor_type)), right? It
would be cool if I could assume that a file descriptor is never larger
than a pointer (no malloc needed), but this is probably too ugly.

  - a


-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com