Re: [RFA/RFC] Replace call_ptrace and ptrace_wait in inf-ptrace.c

[Andrew Cagney <cagney@gnu.org>]

>    > That, however, is a bad idea, since this makes it
>    > impossible for the compiler to properly typecheck the arguments to
>    > ptrace().
> 
>    How so?
> 
> The variety in ptrace(2) prototypes is pretty big.  Arguments can be
> integer or pointer types of various sizes (32-bit, 64-bit).  We simply
> cannot get that right for all supported operating systems.  So we have
> to guess.  Being conservative, we use a long integer type, say
> CORE_ADDR, for the n-th argument of call_ptrace().  Suppose that on an
> LP64 platform we pass, by mistake, a pointer as the n-th argument of
> ptrace, but that argument should really be an int.  Because of the
> intermediate call_ptrace() the compiler doesn't warn us about it.  The
> result is probably a mysterious bug.

Either way we'll end up with casts:
	CORE_ADDR -> (void *)
	(void *) -> long
etc, why not have methods that at least avoid the casts (or do it 
locally to GDB's ptrace code?).

> If we'd used a macro instead, the compiler would have warned us.
> 
>    I've noticed that ptrace can sometimes be declared with a variable 
>    number of arguments, but that just suggests there should be a 
>    gdb_ptrace4() and gdb_ptrace5() with explicitly 4 and 5 arguments.
> 
> Linux does variable number of arguments, although the underlying
> system call isn't.  I believe the 5-arg SunOS-compatible
> PTRACE_READDATA on SPARC Linux simply doesn't work.
> 
> We shouldn't need an explicit 5-arg ptrace.  The fifth argument is
> always zero in GDB.

good news
Andrew