This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86 64 bit function argument bug?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]