Re: S_IFMT not mentioned in any man page

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

N'morning,

Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
 |>>>     No new S_IFMT symbolic names for the file type values of mode_t
 |>>>     will be defined by POSIX.1-2008; if new file types are
 |>>>     required, they will only be testable through S_ISxx( ) or
 |>>>     S_TYPEISxxx( ) macros instead.
 |>> That strikes me as stupid of them.  You can't [switch on
 |>> conditionals]
 |> I think most of the time you're interested in one or two specific
 |> things.
 |
 |(a) That's an artifact of the kind of code you're writing/reading.  I'd
 |    estimate my own code that checks filesystem object types is roughly
 |    evenly balanced (say, 1/3 to 2/3) between "check one or maybe two
 |    particular types" and "switch based on type, with at least three
 |    non-default arms in the switch".
 |
 |(b) Letting "most of the time" drive decisions in ways that leave the
 |    rest of the time out in the cold is a Bad Thing.
 |
 |> As you say, the problem was possibly the direct access to st_mode,
 |
 |I don't think I said that.  I certainly didn't intend to.

Oh no?  So then, i thought i've read that between the lines.

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

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.  How can it be outweighed?
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.
A S_FILETYPE(struct stat) would make sense in my opinion, but it
seems it would never enter any standard.  I wonder why not more
people came to that conclusion.

--steffen