Bruce Evans wrote: > _POSIX_REALTIME_SIGNALS is defined to 0: > This means that the interface may work, and that it exists in headers and > libraries, so applications may reference it in normal ways. It may fail > at runtime; applications must use sysconf() to determine if it is actually
Alternately, they can say "Screw you, OS designer!" and use it as if it were "-1", so that they don't have to add all sorts of runtime garbage to their programs, with multiple alternate code paths, etc.. Makes for much more readable code. > _POSIX_REALTIME_SIGNALS is undefined: > Apparently the same as when it is defined to 0, except you cannot assume > that anything related to it works until you call sysconf(), so you must > not reference its interfaces statically, and must use a dll or something > that references it. The dll is presumably available on systems that > support it but not (except possibly a dummy version) on systems that > don't support it. > > I think the case where the symbol is undefined should never be implemented > in practice. It can be reduced to the case where the symbol is 0 using > dynamic linkage with the complications for linkage not visible to the > application. I think you will have to go back in time, for this to happen. As things stand today, there are systems where it's undefined that were implemented before the symbol was a twinkle in some feature-test weenie on the POSIX committee's eye. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
