Am Sonntag, 4. März 2007 schrieb Per Inge Mathisen: > On 3/4/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > It can't... At least on compile time it is fixed in one way or the other. > > And if eg. 3 is defined to SIGQUIT at compiletime, it can never change > > ever thereafter... If a library compiled with SIGQUIT being 3 would > > communicate with a program compiled with SIGQUIT defined to 4, then they > > would not be able to talk to each other... So this must be a standard, > > otherwise the whole Linux-land would not work... > > It would have to be standardized on the same system (eg Linux), but > for all I know it could be standardized differently on other systems > (eg FreeBSD, MacOSX). > > Not sure how this can best be solved, though. Making wz_strsignal() > use a switch that checks the various SIG* enums and returns a string > for each is one solution. At least on my system SIG* are not enums, but defines... My current wz_strsignal uses the signum as an index into the description table, like strsignal does. I don't know how that is different from a switch. If you know that some signals have a different meaning on another OS, you could use preprocessor checks to give that signum a different description. But I don't think that these system dependend signals will be many, as most of them are either defined by C99 or POSIX. Maybe some of the newer BSD signals have a different meaning on other OSes, I don't know that. But at least they have the same meaning on BSD and Linux, so this leaves only MacOS for which we need to check. I don't even use the defines, but only their numbers, so even on a system where those signals are not defined, we wont get into trouble. If the OS leaves the definition of a certain number empty, I doubt that it will ever send that signal. So I think it is save the way it is... But feel free to fix it however you like.
--Dennis
pgpNBzat2dM1g.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
