tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: S_IFMT not mentioned in any man page

>>> instead of at some S_FILETYPE(struct stat) or whatever, restricting
>>> the scope of system library implementors.
>> It's not much of a restriction; IMO it is outweighed by the things
>> it allows on the caller side of the API.

Actually, providing something like S_FILETYPE() to do what
st_mode&S_IFMT now does would give most of the benefit.  (Would have
given, actually, since there is now a huge installed base to consider.)
Probably me misreading; I initially read you as advocating providing
only the various S_ISxxx() test macros.

> Well you are not free to choose where and how the mode bits are
> stored, they have to be in the single field st_mode or what and must
> be diggable with a simple mask.

Yes, but only at the API.  Nothing says they have to be stored together
on disk - indeed, nothing says they have to be stored at all, if they
can be derived from something else.  And, no matter what your
S_FILETYPE() looks like, every filesystem implementation would have to
conform to it, so you really wouldn't've gained much.

> How can it be outweighed?

By supporting direct switch() on the type.  (As I said, I (mis)read
what you wrote....)

> Well i'm all for freedom but that also means freedom of implementors,
> here they have deal with a very hard and complicated task.  Just
> recall all that struct stat mess, with stat64 etc.

What's stat64?  I just did a search through /sys on my most recent
NetBSD rev (5.2) and the only occurrences of "stat64" I found anywhere
were in compat/.

> A S_FILETYPE(struct stat) would make sense in my opinion,

Perhaps, but I don't see it as having much benefit over the existing
scheme (especially in view of the installed base).  All filesystem
implementations would still have to generate the same data structure,
whether it consisted of today's st_mode or not.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index