Re: S_IFMT not mentioned in any man page

[Steffen Nurpmeso <steffen%sdaoden.eu@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
 |>>> 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.

No, i was not.  I showed understanding for POSIX doing so for
future code for encapsulation purposes.  On the hand, since you
need to pass st_mode...

 |> 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.

Yes all that can or has to be assembled anyway.  And with a 64-bit
st_mode it seems even cloud-services can be expressed as
filetypes..  Sure.

 |> How can it be outweighed?
 |
 |By supporting direct switch() on the type.  (As I said, I (mis)read
 |what you wrote....)

Yep (to the first part).

 |> 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/.

Oh don't ask me, this is a mishmash from header files i have ever
seen.  Add "ostat" or something similar.  If you argue against
POSIX then it is not fair to only look into NetBSD /usr/include,
right?

 |> 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.

True, as above.  It was just a mapping of what i had in C++,
something that i as a Unix newcomer thought after Y 2000.  I.e.,
i did actually not end up with the same or a similar scheme, which
i thought being possibly interesting.  So that is me, i do
understand that POSIX wants to move, but i don't like the
remaining approach either (since it lands on st_mode instead of
simply taking struct stat*).  On the other hand it is fascinating
that even today st_mode/m_ino/st_dev/st_rdev are sufficient to
express the file world (the latter three being Unix only)!
Oh You Pretty Things!

--steffen