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

[Richard O'Keefe]

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 <sys/stat.h> 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?