This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: x86 64 bit function argument bug?
- From: Falk Hueffner <falk dot hueffner at student dot uni-tuebingen dot de>
- To: Stephen Biggs <xyzzy at hotpop dot com>
- Cc: GCC list <gcc at gcc dot gnu dot org>
- Date: 04 May 2003 15:22:04 +0200
- Subject: Re: x86 64 bit function argument bug?
- References: <1052069756.5505.43.camel@steve.softier.local>
Stephen Biggs <xyzzy@hotpop.com> writes:
> The following weird 2 lines of C code (yes, I know taking the address of
> a disappearing entity is an evil thing!):
> int *i ( int arg ) { return &arg; }
> long long *ll ( long long arg ) { return &arg; }
Since it is impossible to use the resulting pointer without invoking
undefined behaviour, I don't think it is particularly interesting what
code is generated. We should probably warn about that.
> Note that the 2.4 Linux kernel depends on this compiling as it expects
> in at least one place that I know of:
>
> net/core/neighbour.c
> void neigh_destroy(struct neighbour *neigh)
> {
> struct hh_cache *hh;
>
> if (!neigh->dead) {
> printk("Destroying alive neighbour %p from %08lx\n",
> neigh,
> *(((unsigned long*)&neigh)-1));
> return;
> }
This is different. The address of the argument is not returned.
However, this code contains undefined pointer arithmetics plus an
aliasing violation, and just generally doesn't make a lot of sense.
> If it is not a bug and is expected behavior, can anybody think of
> any sort of fairly portable work around?
Maybe if you told us what that code is supposed to do.
--
Falk