struct stat POSIX naming issue

[andreasf]

According to Open Group, struct stat has mandatory members st_mtim etc. ​http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html

In posix/sys/stat.h they are called st_mtime etc. instead. Notice the extra letter.

This breaks recent Git builds.

Is this POSIX deviation for BeOS compatibility, or did simply no one complain yet?

[andreasf]

fixed stat.h

[andreasf]

I replaced time_t st_mtime with struct timespec st_mtim and added compatibility macro st_mtime st_mtim.tv_sec, as outlined above.

Makes Git happy there.

[axeld]

This change would break binary compatibility, though. This change has been made in Issue 7 of the specs. Through the BeOS API detection, we could change this, but this would then require us to recompile all optional packages.

Wouldn't it be POSIX, I also wonder why they didn't adopt the BSD version of this, and called them st_mtimespec etc.

[bonefish]

Since we generally support BeOS drivers, this change will also require API remapping in the kernel. Also, file systems should fill in the tv_nsec field correctly.

Will look into this later tonight.

[bonefish]

Unfortunately this turns out to be seriously non-trivial, since the stat structure is not only passed to a handful of POSIX functions, but is also used in the Be API -- worst of all virtual methods like BRefFilter::Filter() and BStatable::GetStat(). ATM I don't see a solution other than forking off compatibility versions of the concerned libraries.

Suggestions welcome.

[axeld]

I've probably overseen something, but can't we just call BRefFilter::Filter() with the stat as suggested by the binaries ABI version? And for GetStat(), we would use the "right" version of fstat() again depending on the ABI version of the caller?

The former might still be problematic in mixed environments (add-ons vs. app), but that shouldn't happen very often, anyway.

[bonefish]

Replying to axeld:

I've probably overseen something, but can't we just call BRefFilter::Filter() with the stat as suggested by the binaries ABI version? And for GetStat(), we would use the "right" version of fstat() again depending on the ABI version of the caller?

The former might still be problematic in mixed environments (add-ons vs. app), but that shouldn't happen very often, anyway.

Not only add-ons would be a problem, but also libraries. And we don't control who calls BRefFilter::Filter() -- I believe it's only BFilePanel in the Be API, but an application or library could use the class for its own purposes as well. BStatable::GetStat() is really the lesser problem, since one can't even derive classes from BStatable.

A safe solution (besides compatibility libraries) would be to introduce a struct stat_beos which resembles the old struct stat, and use it in BRefFilter::Filter() and BStatable::GetStat(). In case of BRefFilter this would break source compatibility, in case of BStatable we could use a reserved virtual slot to prevent that, though.

[bonefish]

Implemented as I proposed in hrev30830.