Re: [Haskell-cafe] Re: How Can Haskell Be Saved?

On Dec 14, 2009, at 3:44 PM, Erik de Castro Lopo wrote:

Richard O'Keefe wrote:

...

I also pointed out that Windows NT had a fully compliant POSIX subsystem, by design, and that Microsoft cared at least enough about POSIX support to buy the company that made what is now SUA.

How does that explain things like fstat() and stat() returning different values for the same file:

http://www.mega-nerd.com/erikd/Blog/Windiots/posix.html

That bug exists in windows XP, Vista and 7.

I did mention the "DeathStation 9000" label it has earned. I actually got that from your web site. I got this bug report there too. I am an anti-Microsoft bigot. I go around saying that if this University were really opposed to software piracy, we'd ban all Microsoft products. But I hope you like horror stories, because in _this_ case, while all sanity and practicality are on one side, Microsoft are fully within their legal rights to be on the other. The Single Unix Specification, version 4 (POSIX.1-2008) defines what fstat(), fstatat(), stat(), and lstat() should do to st_size for - shared memory objects - typed memory objects - symbolic links For other file types, the structure members st_mode, st_ino, st_dev, st_uid, st_gid,st_atim, st_ctim, and st_mtim shall have meaningful values and the value of the member st_nlink shall be set to the number of links to the file. That is, st_size is specifically *not* defined and need *not* have "meaningful values". The description of st_size in says "For regular files, the file size in bytes", but I repeat, the specifications of fstat() and stat() do NOT say that it is given any meaningful value at all for regular files. An implementation where fstat() always fills in 0xDEAF and stat() always fills in 0xDEAD would not fail to conform to POSIX for that reason alone. By any sane or practical standard, the discrepancy between stat() and fstat() in Windows is a bug. By the standard of conformance to POSIX, it isn't. (By the way, the mention of st_[acm]tim instead of st_[acm]time is not a typo above. The old time_t members are gone. The new ones are struct timespec-s, which looks very much the 2038 bug is still with us.) Except for this change, the Single Unix Specification version 3 is not much different from V4, in particular, V3 didn't require a POSIX system to set st_size to anything useful for a regular file either. The moral of the story is - Microsoft have excellent lawyers - standards may promise far less than you think

You would think that Microsoft's much touted POSIX support would mean that the POSIX calls I used on *nix would JustWork(tm) on windows. Unfortunately, due to bugs in Microsoft's POSIX implementation this is not the case. Bugs include:

- fstat() (64 bit file length aware version) returning the wrong file length after a write (win9x).

It doesn't have to return ANYTHING sensible, EVER, for a regular file.

- lseek() (64 bit file length aware version) to SEEK_END not actually going to the end of the file (win2000 and win2003).

That one looks like a real bug. Is it still there in Vista and Windows 7?

- fstat() and stat() returning different results on the same file (XP, Vista and 7).

They don't have to return ANYTHING sensible, EVER, for regular files, and they DON'T have to agree. You are completely absolutely 100% right that the {,f}stat() issues are deplorable and that any company having a decent respect for its customers would fix the problem. But it _is_ legal POSIX behaviour. Which is why I'm not so terribly impressed when John Earle said that about Apple and Microsoft not adopting POSIX. POSIX is fine, but it isn't perfect. Microsoft shows that "adopting" POSIX doesn't ensure producing something _good_; Apple show that not quite adopting POSIX doesn't mean what you have is necessarily _bad_. Can we get back to "How Can Haskell Be Saved" now?