llvm dev - Jul 2011 - [LLVMdev] mismatched function signatures

Hi,

Suppose I have a function

define void @foo(i4 %a) {
  %ptr = alloca i4
  store i4 %a, i4* %ptr
  ...
}

but in the following the function is used by a wrong signature,

%f = bitcast void(i4)* @foo to void(i8)*
call void %f (i8 17)

then what is the value of %a when @foo is called, will the 255 be
truncated into a value of i4, for example 1, like what trunc does?

It seems fine if the mismatched types are the types that can work with
trunc or ext. But other types, for example, structs, may not work. In
general, if a parameter is of type t1, and its argument is of type t2,
what value of the argument can we expect? Will it be a random value of
type t2?

Thanks.
-- 
Jianzhou

> It seems fine if the mismatched types are the types that can work with
> trunc or ext. But other types, for example, structs, may not work. In
> general, if a parameter is of type t1, and its argument is of type t2,
> what value of the argument can we expect? Will it be a random value of
> type t2?
The call to function with mismatched signature yields undefined
behavior. So, everything can happen. E.g. you can expect that the
binary will format your hard drive and steal your cookies :)

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Thu, Jul 21, 2011 at 4:29 AM, Anton Korobeynikov
<anton at korobeynikov.info> wrote:
>> It seems fine if the mismatched types are the types that can work with
>> trunc or ext. But other types, for example, structs, may not work. In
>> general, if a parameter is of type t1, and its argument is of type t2,
>> what value of the argument can we expect? Will it be a random value of
>> type t2?
> The call to function with mismatched signature yields undefined
> behavior. So, everything can happen. E.g. you can expect that the
> binary will format your hard drive and steal your cookies :)
Yes. Then will the undefined behavior, say, formatting hard drive :)
happen exactly when calling functions with wrong arguments, or be
delayed until these wrong arguments are used, (for example, when being
stored into memory)? The similar problem is out-of-bound memory
access. getelementptr (w/o inbounds flag) can still return an
out-of-bound location if it is given wrong indexes, and the undefined
behavior only happens when there are load/store at the location. Did I
miss any case where any worse situation can happen at call sites?
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>


-- 
Jianzhou