Consider the following function
/*@
assigns \nothing;
ensures a == 0;
*/
void foo(int a)
{
a = 0;
}
The postcondition can of course not be verified because the assignment happens to a copy "a" and furthermore nothing is known about the value of "a" in the pre-state.
If I add, however, the admittedly weird looking precondition "requires \valid(&a);" as shown here
/*@
requires \valid(&a);
assigns \nothing;
ensures a == 0;
*/
void bar(int a)
{
a = 0;
}
then Qed discharges the postcondition.
I am not sure this a bug or rather caused by taking the address of a formal argument in the precondition
but in any case it would be nice if someone could have a look at it.

Indeed, formals are not (yet) allocated in the pre-state, although they are allocated just before the first statement of the body... This is a corner case, of course.
Typically, the following program is proven:
*@ requires \valid(&a); ensures \false; */
void f(int a) {
return ;
}
But, then, the following one fails with a WP error:
void g(int x) { f(x); }
[wp] User Error: Address of logic value (x_0)
This is because, when you instantiate the pre-condition of f with the formal parameters, you get an incorrect
expression with (&a).

Side note : we are also working on running smoke tests to detect infeasible requires (those that would allow to prove false).
Second side node : probably it would be a good idea to detect the usage of (&x) on a formal (x) inside pre-conditions.

Third side note: this would also warrant a clarification in the ACSL manual itself, because at the moment there is nothing in it that precludes the usage of \valid(&a) in a requires.
By the way what would be the status of \valid(&a) in an ensures clause?

For the same reason, `\valid(&a)` is not valid in the ensures clause, also it is still valid just at the end of the body.
Although, `\valid(&a)` reveals the same problem of accessing the address of values when used at call-sites.
Actually, the Kernel shall reject any access to the address of a formal inside a function specification.