[comp.lang.c] 0 and pointers.

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