The following is an example code in C.
unsigned int COUNTER;
unsigned int get_counter(void) {
COUNTER ++;
return COUNTER;
}
I wrote its founctional spec using verifiable c (vst), but at the end of the verification I encounter an error "typecheck_error (deref_byvalue tint)". Could any body tell me how to write a correct founc spec of the above c founction?
The point is how to write a global variable's SEP().
(here is the incorrect one, please correct me)
Definition get_counter_spec :=
DECLARE _get_counter
WITH v : Z, counter:val
PRE []
PROP ()
LOCAL (gvar _COUNTER counter)
SEP (data_at Ews tint (Vint (Int.repr v)) counter)
POST [ tint ]
PROP ()
LOCAL(temp ret_temp (Vint (Int.repr (v+1))))
SEP (data_at Ews tint (Vint (Int.repr (v+1))) counter).
Your bug: in the C program, COUNTER is declared "unsigned int", but in your get_counter_spec, you use "tint" instead of "tuint". With that change, the proof goes through right away: start function; do 4 forward.
Our bug: The error message you get (in VST 2.0) is quite useless! I will add an issue-report to improve the error reporting in this kind of case.
Related
I think I am missing a part of technical background. But I don't get, why I have to use an * to access the value of a simple pointer, but not for accessing values of a struct.
For example with a simple value:
func main() {
i := 42
p := &i
*p = 21 // <<< I have to use an asterisk to access the value
// ...
}
And a example with a struct:
type Vertex struct {
X int
Y int
}
func main() {
v := Vertex{1, 2}
p := &v
p.X = 1e9 // <<< I do not have to use an asterisk
// ...
}
(yes, the samples are from the official go lang tour here: https://go-tour-de.appspot.com/moretypes/4)
Just from my thoughts I would expect something like this
*p.X = 1e9
or (yeah, this would be somewhat strange)
p.*X = 1e9
So, why don't I have to use an asterisk to access struct pointer?
The official Golang tour where you found that example [here] explicitly says:
To access the field X of a struct when we have the struct pointer p we could write (*p).X. However, that notation is cumbersome, so the language permits us instead to write just p.X, without the explicit dereference.
I know using & symbol address the address of the stored value, but as I'm going the "Tour of Go", in the sections where they introducing pointers and special receivers, they have code as follow for referring to a Vector struct to scale and get the absolute value as shown:
package main
import (
"fmt"
"math"
)
type Vertex struct {
X, Y float64
}
func (v *Vertex) Scale(f float64) {
v.X = v.X * f
v.Y = v.Y * f
}
func (v *Vertex) Abs() float64 {
return math.Sqrt(v.X*v.X + v.Y*v.Y)
}
func main() {
v := &Vertex{3, 4}
fmt.Printf("Before scaling: %+v, Abs: %v\n", v, v.Abs())
v.Scale(5)
fmt.Printf("After scaling: %+v, Abs: %v\n", v, v.Abs())
}
With an output of:
Before scaling: &{X:3 Y:4}, Abs: 5
After scaling: &{X:15 Y:20}, Abs: 25
But if I change the main function call to have v := Vector{3.4} instead of v:= &Vector{3.4}, I get the same output. Is it better practice to refer to the memeory address in this case? More of a conceptual circumstance I don't seem to understand.
You will not get the exact same output, notice that the output no longer indicates that you've passed a pointer (the & is missing):
Before scaling: {X:3 Y:4}, Abs: 5
After scaling: {X:15 Y:20}, Abs: 25
The reason you can still call the absolute value method is because Go implicitly takes the address of v for you when it sees that the method exists on a pointer type but you've used the struct directly since it is always possible to take the address of the struct and derive a method call on the pointer receiver.
For more information, see the "Method expressions" section of the Go spec: https://golang.org/ref/spec#Method_expressions
There isn't really enough information in this specific instance to tell you whether it's good or bad practice to use the struct value or always pass a pointer around. This is very dependent on the situation, the size of the struct, whether you want your value stack or heap allocated, and any number of other factors. However, for most programs it probably won't make a difference and I'd advise that it's not worth worrying about early on as you learn Go.
I'm learning Go from a Java/Python background, and am confused by this code from the Go tutorial. In the following code, the line
p.X = 1e9
sets the value of v.X to 1e9 using pointer p. As p is merely a pointer to v, isn't dereferencing necessary to set v's value? Thus the correct statement would be:
*p.X = 1e9
Naturally, this results in an error. Can someone explain why the Go example code works as it is?
Code in question:
package main
import (
"fmt"
)
type Vertex struct {
X int
Y int
}
func main() {
v := Vertex{1, 2}
p := &v
p.X = 1e9
fmt.Println(v)
}
In go, the compiler automatically converts the expression to (*p).X. From the the language spec:
if the type of x is a named pointer type and (*x).f is a valid
selector expression denoting a field (but not a method), x.f is
shorthand for (*x).f.
I think I understand what pointer is but I don't quite understand when to use it.
The below snippet is from "A Tour of Go".
What is the purpose of "*Vertex" and "&Vertex"?
I replaced them with "Vertex" and it run fine.
package main
import (
"fmt"
"math"
)
type Vertex struct {
X, Y float64
}
func (v *Vertex) Abs() float64 {
return math.Sqrt(v.X*v.X + v.Y*v.Y)
}
func main() {
v := &Vertex{3, 4}
fmt.Println(v.Abs())
}
That's not a particularly good example of the pointer/value distinction, because in that case they're interchangeable! Pointers are useful when you need to mutate data "remotely" (from another function).
func (v Vertex) SetX(x int) {
v.X = x
}
func main() {
v := Vertex{3, 4}
fmt.Println(v)
v.SetX(1)
fmt.Println(v)
}
As you'll note, this doesn't change anything (strictly speaking, it changes a copy of the vertex, but that's just semantics in most cases)! The value of v is still {3,4}. Trying instead with:
func (v *Vertex) SetX(x int) {
v.X = x
}
func main() {
v := &Vertex{3, 4}
fmt.Println(v)
v.SetX(1)
fmt.Println(v)
}
And suddenly, it works, the second time it prints {1,4}. Now, if you're curious, you may decide to experiment and change v := &Vertex{3, 4} to v := Vertex{3, 4}. Indeed, the above snippet still works. Strange. Likewise, if you change the same line in the second snippet to contain a pointer, it also works the same way.
Why? Go has "transparent" pointers. In other languages with explicit pointer values like C or C++, you have to explicitly use the operators & and * to dereference a pointer. C and C++ even have special syntax for pointer chasing on field access and method calls v->SetX.
For better or worse, Go hides this from you. If you have a value and need to call a pointer method, Go will happily do (&v).Method() for you, if you need to dereference to call a value method, it happily does (*v).Method() automatically. This is true in most cases, there are a few corner cases with things like maps where this doesn't apply, but in general this holds.
So, when it comes down to it, when should you use a pointer receiver on a method? The answer, really, is "most of the time." The Go Style Guide generally recommends using pointer type method receivers except when the receiver is a direct alias for a map, func, or chan, it's a slice that doesn't need reslicing, or you're doing optimizations on small, immutable data types (because pointer chasing is a little bit slower than copying). I'd add to that that you generally shouldn't use direct pointers to pointers.
Generally, when you have no idea which to use, use a pointer receiver. 99% of the time using a pointer will give you the behavior you expect, especially if you're used to languages like Python or C#. It's comparatively rare that incorrectly using a pointer causes a bug, compared the probability of getting a bug because your Setter method isn't actually setting anything.
This particular example is bad because the method defined on pointer type, *Vertex, does not attempt to mutate the value of its receiver (the value the method is called on).
In Go, everything is ever passed/assigned by value — including pointers. So, when you have a method
func (v Vertex) Abs() float64 {
return math.Sqrt(v.X*v.X + v.Y*v.Y)
}
(notice there's no * in front of Vertex in the receiver's type specification), it works just OK because when you do
v := Vertex{2, 3}
x := v.Abs()
the value of v at the v.Abs() call site is copied to the value the Abs() method receives.
Now suppose you want to change (mutate) some of the Vertex's variables using a method call. A naive approach, like in,
func (v Vertex) SetX(x float64) {
v.X = x
}
v := Vertex{2, 3}
v.SetX(-5)
// Here, v.X is still 2
won't work because it will change X of the value v which has been copied to the callee when the call was made; the method changed the X of the copy—a change only seen in the method's scope.
On the other hand, if you were to define that method on the pointer (which holds the address of an actual variable holding a value instead of the value itself), that would work:
func (v *Vertex) SetX(x float64) {
v.X = x
}
v := Vertex{2, 3}
v.SetX(-5)
Here, the compiler would take the address of v at the point SetX() is called and pass it to the method. The method would then use that address to refer to the value in the caller's scope.
The syntactic confusion is because Go (in most cases) allows you to not use operators to take address of a value and dereference that address.
If you're coming from one of popular languages like PHP, Python etc the chief difference is that in many of them objects are "special" and are always passed by reference. Go is more low-level and tries not to use magic behind programmer's back, so you have to be explicit about whether you want to pass a pointer or a copy of the value to a method.
Note that this is not only about whether a method is able or is not able to mutate its receiver; performance things might also play a role here.
I am new to GoLang, coming from the Delphi, C++ world - admittedly very excited about this language, which I think is destined to become "the next big thing".
I am trying to get a handle around how the Go parser and compiler handle pointers and references - can't seem to find any place where some clear rules are laid out.
In the below code sample for example, the return type *list.List and the local variable l are pointer types and require the pointer symbol * in their declarations, but they don't have to be dereferenced in use: l.PushBack(i). But in this same code the input parameter value *int64 is declared as a pointer and has to be dereferenced to be used properly: var i int64 = *value / 2
I assume that this is because list.List is a reference type, so the dereferencing is implicit when used, while int64 is a value type and must be handled just as any pointer to a value type, as in C++ for example: It must be dereferenced.
What is confusing to me is that even though *list.List has to be declared as a pointer type using *, when using the list instance, dereferencing is not required. This had me quite confused initially. Is that "just the way it is", or am I missing something?
Sample:
func GetFactors(value *int64) *list.List {
l := list.New()
l.PushBack(*value)
var i int64 = *value / 2
for ; i > 1; i-- {
if *value%i == 0 {
l.PushBack(i)
}
}
return l
}
All of the methods for a List have *List receivers: (http://golang.org/pkg/container/list/)
func (l *List) Back() *Element
func (l *List) Front() *Element
func (l *List) Init() *List
...
func (l *List) Remove(e *Element) interface{}
In your example l is of type *List, so there's no need to dereference them.
Suppose, instead, that you had something like this:
type A struct{}
func (a A) X() {
fmt.Println("X")
}
func (a *A) Y() {
fmt.Println("Y")
}
You are allowed to write:
a := A{}
a.X()
a.Y() // == (&a).Y()
Or you can do the following:
a := &A{}
a.X() // same like == (*a).X()
a.Y()
But it only works for method receivers. Go will not automatically convert function arguments. Given these functions:
func A(x *int) {
fmt.Println(*x)
}
func B(y int) {
fmt.Println(y)
}
This is invalid:
A(5)
You have to do this:
var x int
A(&x)
This is also invalid:
var y *int
B(y)
You have to do this:
B(*y)
Unlike C# or Java, when it comes to structs, Go does not make a distinction between reference and value types. A *List is a pointer, a List is not. Modifying a field on a List only modifies the local copy. Modifying a field on a *List modifies all "copies". (cause they aren't copies... they all point to the same thing in memory)
There are types which seem to hide the underlying pointer (like a slice contains a pointer to an array), but Go is always pass by value.