djones@megatest.UUCP (Dave Jones) (10/07/89)
By the way, here's a mistake I see quite often. It makes no difference on many machines, but on architectures where casting an integer to a pointer in not a NOP, you are in trouble with this: foo() { char *mem = (char*)malloc(STRLEN); /* etc... */ } Of course you should say, extern char* malloc(); foo() { char *mem = malloc(STRLEN); /* etc. */ }
decot@hpisod2.HP.COM (Dave Decot) (10/13/89)
> They were probably following BSD's lead. BSD UNIX at one point started > passing additional information to signal handlers for certain classes of > signals (e.g. FPE exceptions). This is horribly nonportable, as is > treating fixed-argument functions the same as variadic functions. > > Anyway, it's wrong. The standard signal() function's signal handlers > are NOT variadic; they receive precisely one int argument. This is why many operating systems on which C is used have had to add some other interface (or if they can do it compatibly, add arguments to the handling function) to workaround this design defect. I don't know how "horribly" non-portable this usage is, since many systems seem to be able to acheive it, but if the standard defined something useful, there wouldn't be as much need to invent non-portable ways to get the job done. Dave Decot
henry@utzoo.uucp (Henry Spencer) (10/14/89)
In article <2550107@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >> Anyway, it's wrong. The standard signal() function's signal handlers >> are NOT variadic; they receive precisely one int argument. > >This is why many operating systems on which C is used have had to add >some other interface (or if they can do it compatibly, add arguments to >the handling function) to workaround this design defect... The point is not that more arguments are not useful, nay, important; the point is that arbitrarily changing the specs for signal handlers was a terrible mistake and very unportable. Defining a new interface is the right approach. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
decot@hpisod2.HP.COM (Dave Decot) (10/17/89)
> The point is not that more arguments are not useful, nay, important; the > point is that arbitrarily changing the specs for signal handlers was a > terrible mistake and very unportable. Defining a new interface is the > right approach. Since the variadic functions in questions are the signal handlers, designing a new interface that permits preserving old behavior seems very difficult. Dave
henry@utzoo.uucp (Henry Spencer) (10/17/89)
In article <2550109@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >> ... arbitrarily changing the specs for signal handlers was a >> terrible mistake and very unportable. Defining a new interface is the >> right approach. > >Since the variadic functions in questions are the signal handlers, designing >a new interface that permits preserving old behavior seems very difficult. No it's not; you just need a new variant of signal() which is used when establishing a variadic handler. (In POSIX, actually, it's easier than that, because the POSIX equivalent of signal() has a "flags" field in the structure it receives.) Then the system knows whether the handler is normal or variadic and can cope accordingly. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu