>>>>> "Fons" == Fons Rademakers <Fons.Rademakers@cern.ch> writes:
Fons> It has not so much to do with *design* as finding out how the
Fons> different lib C implementers interpreted the standard (or the
Fons> compiler implementers for that sake). You've to read a lot of FM's
Fons> and header files. ;-)
No if you read the standard it will tell you that it's not an integral
type as Dan said. Basically you shouldn't do a direct comparison on any
system type thats a _t unless the documentation for the type explicitly
states you are allowed to do so.
Fons> For a nice example where RTFM did not help much see:
Fons> http://root.cern.ch/lxr/source/unix/src/TUnixSystem.cxx#1863
Fons> Here good design would have lead to being able to run on only a
Fons> few platforms and not 14.
Why didn't you read the manual instead? From Linux it says:
`sighandler_t sa_handler'
This is used in the same way as the ACTION argument to the
`signal' function. The value can be `SIG_DFL', `SIG_IGN', or
a function pointer. *Note Basic Signal Handling::.
By simply type casing to sighandler_t you would have gotten around most
of this cruft. Even then it would have been significantly cleaner to
define sighandler_t in a header file for those OSes where it does not
exist so it could be used everywhere in the code instead of sticking
those ugly #ifdef's directly into the code. IRIX does seem to have
sighandler_t for instance, though Solaris 2.6 does seem to.
Jes
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:34 MET