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.
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 
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?
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?
That's not quite how UB works. UB taints the entire execution - before
or after the actual runtime point at which UB was invoked. Chris
posted a 3 part blog series on the subject starting here:
(for example - going off array bounds could lead the compiler to just
assume the bounds are correct & make certain optimizations, or if it
can prove the bounds are incorrect it could assume that the out of
bounds code was unreachable & not compile it into the product at all
(perhaps from there proving/assuming that some condition must always
be false & removing the condition test too, etc...))
- David