Will the GCC Compiler correctly handle the following?
uint32 fn(uint32 adr, uint8 *ptr) {
return (ptr==adr);
}
In other words will it auto cast ptr to an integer that stores the memory address pointed to?
Yes, GCC will handle it correctly -- by diagnosing the error in your code.
C has no implicit conversions between integer types and pointer types (other than the special case of an integer constant 0 being treated as a null pointer constant), and == cannot compare values of integer and pointer type.
To correct the error, add a cast (an explicit conversion) to convert adr to type uint8*:
return ptr == (uint8*)adr;
or, even better, make the two parameters of the same type in the first place:
uint32 fn(uint8 *adr, uint8 *ptr) {
return ptr == adr;
}
Unless you have some specific reason that adr needs to be an integer rather than a pointer, but you haven't told us what that reason might be.
C is more strongly typed that a lot of people assume it is.
Related
My application accepts a pointer from os.Args.
For example
pointer := os.Args[1] //"0x7ffc47e43200"
How can I use that pointer and get the value that is stored on that location?
Disclaimer: As you are probably aware, this is dangerous and if you're going to do this in a production application, you'd better have a really good reason. That being said...
You need to do a few things. Here's the code, and then we'll walk through it.
package main
import (
"fmt"
"os"
"strconv"
"unsafe"
)
func main() {
str := "7ffc47e43200" // strconv.ParseUint doesn't like a "0x" prefix
u, err := strconv.ParseUint(str, 16, 64)
if err != nil {
fmt.Fprintln(os.Stderr, "could not parse pointer:", err)
os.Exit(1)
}
ptr := unsafe.Pointer(uintptr(u)) // generic pointer (like void* in C)
intptr := (*int)(ptr) // typed pointer to int
fmt.Println(*intptr)
}
You can run this on the Go Playground.
First, we need to parse the string as a numerical value. In your example, you gave a hexadecimal number, so we'll parse in base 16 (that's the "16" argument to strconv.ParseUint). Note that strconv.ParseUint doesn't like the "0x" prefix, so I removed it.
Then, we need to convert the number into a pointer type. For this, we will use the unsafe.Pointer type, which is special to the Go compiler. Normally, the compiler won't let you convert between pointer types. The exception is that, according to the unsafe.Pointer documentation:
A pointer value of any type can be converted to a Pointer.
A Pointer can be converted to a pointer value of any type.
A uintptr can be converted to a Pointer.
A Pointer can be converted to a uintptr.
Thus, in order to convert to a pointer, we'll need to first convert to a uintptr and then to an unsafe.Pointer. From here, we can convert to any pointer type we want. In this example, we will convert to an int pointer, but we could choose any other pointer type as well. We then dereference the pointer (which panics in this case).
I am new to Go, and I am studying its interface feature.
Here is the code:
package main
import (
"fmt"
"reflect"
)
type Integer int
func (a Integer) Less(b Integer) bool {
return a < b
}
func (a *Integer) Add(b Integer) {
*a += b
}
type LessAdder interface {
Less(b Integer) bool
Add(b Integer)
}
var a Integer = 1
var b LessAdder = &a
func main() {
fmt.Println(reflect.TypeOf(b))
fmt.Println(b.Less(2))
b.Add(a)
fmt.Println(a)
}
And it will output the the following:
*main.Integer
true
2
Well, this works pretty well.
The Point is:
How var b LessAdder = &a works. Does the pointer auto-dereference happens right here, or when b invokes member method?
The output *main.Integer tells us that b is a pointer to type Integer, hence it is the second case.
Then the tricky thing comes:
when I add fmt.Pringln(*b) to the code, the compiler comes with an error:
demo/demo1
./demo1.go:31: invalid indirect of b (type LessAdder)
And it confuses me. Since b is a pointer type to Integer, then dereferencing it should work. But why not?
Your last sentence:
"Since b is a pointer type to Integer, then dereferencing it should work."
Stop right there. b is not a variable of pointer type and therefore you can't dereference it.
It is a variable of interface type which is schematically a pair of a value and a type (value,type), holding &a as the value and *Integer as the type (blog article The Laws of Reflection, section The representation of an interface).
This is a declaration of a variable of pointer type, *Integer:
var ip *Integer
And this is one of an interface type:
var intf LessAdder
When you do this:
var b LessAdder = &a
What happens is that an interface value (of type LessAdder) is created automatically/implicitly which will hold the value &a (and the type *Integer). This is a valid operation because the type of &a (which is *Integer) implements the interface LessAdder: the method set of *Integer is a superset of the interface LessAdder (in this case they are equal, the method set of an interface type is its interface).
Now when you call b.Less(2), since Less() has a value receiver, the pointer will be dereferenced and a copy of the pointed value will be made and used/passed as the value receiver of the method Less().
fmt.Println(reflect.TypeOf(b)) doesn't lie, but it will print the dynamic type of b. The dynamic type of b is indeed *Integer, but the static type of b is LessAdder and the static type is what determines what you can do with a value and what operators or methods are allowed on it.
LessAdder is declared as an interface with the methods Less and Add. Since Add is declared with a receiver of *Integer, a *Integer can be a LessAdder; an Integer can't. When you do var b LessAdder = &a, it's the pointer to a that's stored in the interface b.
The automatic indirection occurs at the call to b.Less(2), because both methods on *Integer and methods on Integer contribute to the method set of *Integer.
You can't use *b because although b contains a *Integer, statically its type is LessAdder, not *Integer. Leaving aside the representation of interfaces, LessAdder isn't a pointer type, and *b, if it was allowed, would have no expressible type at all.
You can use a type assertion to access b as an Integer * again; b.(*Integer) is an expression of type *Integer, and *b.(*Integer) is an Integer. Both of these will run-time panic if the value in b is not a *Integer after all.
I'm just a little bit confused.
When should I use nullptr?
I've read on some sites that it should always be used, but I can't set nullptr for a non-pointer for example:
int myVar = nullptr; // Not a pointer ofcourse
Should I always use NULL non-pointers and nullptr for pointers?
Thanks to any help! I'm very new to c++ 11 (and c++ overall).
Always use nullptr when initializing pointers to a null pointer value, that's what it is meant for according to draft n3485.
[lex.nullptr] paragraph 1
The pointer literal is the keyword nullptr. It is a prvalue of type
std::nullptr_t. [ Note: std::nullptr_t is a distinct type that is
neither a pointer type nor a pointer to member type; rather, a prvalue
of this type is a null pointer constant and can be converted to a
null pointer value or null member pointer value. [...] — end note ]
Now onto the use of NULL.
According to the same draft it shall be defined as follows.
[diff.null] paragraph 1
The macro NULL, [...] is an
implementation-defined C ++ null pointer constant in this
International Standard.
and null pointer constant as follows.
[conv.ptr] paragraph 1
A null pointer constant is an integral constant expression [...]
prvalue of integer type that evaluates to zero or a prvalue of type
std::nullptr_t.
That is, it is implementation-defined behavior whether NULL is defined as an integer prvalue evaluating to zero, or a prvalue of type std::nullptr_t. If the given implementation of the standard library chooses the former, then NULL can be assigned to integer types and it's guaranteed it will be set to zero, but if the later is chosen, then the compiler is allowed to issue an error and declare the program ill-formed.
In other words, although conditionally valid [read IB], initializing an integer using NULL is most probably a bad idea, just use 0 instead.
On the other hand, according to the above NULL is guaranteed to initialize pointers to a null pointer value, much like nullptr does, but while NULL is a macro, what accompanies several caveats, nullptr is prvalue of a specific type, for which type checking and conversion rules apply. That's mostly why nullptr should be prefered.
consider the two function overloads:
void foo(int)
void foo(int*)
in C++, people tend to use 0 as a null value. Other people use NULL. (NULL is really just a fancy macro for 0)
If you call foo(0) or foo(NULL), it becomes ambiguous which one should be called. foo(nullptr) clears up this ambiguity, and will always call foo(int*).
I have written the code below on Qt,when I put values in it it program.exe stops working.
struct aim
{
int i : 1;
int j : 1;
};
int main()
{
aim missed;
printf("Enter value of i :: ");
scanf("%u",missed.i);
printf("Enter value of j :: ");
scanf("%u",missed.j);
}
can anyone help me out with this problem?
There are a few problems with your code:
A 1-bit signed integer isn't very useful, it can only hold the values -1 and 0.
You can't have a pointer to a bit-field, that's not what pointers mean.
Also, there's nothing in the %d specifier that tells the scanf() function that the target value is a bit field (nor is there any other % specifier that can do this, see 2).
The solution is to scanf() to a temporary variable, range-check the received value, then store it in the bit field.
Because the C/C++ standard does not allow to access the members of a bitfield via a pointer and you have to pass scanf a pointer.
I know what pointers are but when it comes to strings/arrays I get really confused. If someone has an answer or a website that explains it that would be great. For example:
char * strncopy (char*dest, char * source, size_t);
Why the pointer? what is it pointing to? Does it a pointer usually store an address?
It is sayed in my textbook that each string building function is of type pointer char*.
Also I was trying to see if I could write a program that would clear things up, but it didn't work. Can someone tell me how to fix it, or what I'm doing wrong.
#include <stdio.h>
#include <string.h>
char * getname ()
{
char name [10];
scanf ("%s", name);
return (name);
}
int main (void)
{
char name[10];
printf ("Enter your name\n");
name[] = getname();
printf ("Hi %s", name);
return (0);
}
Inside of your getname function, when you return a pointer to the name array because it's allocated on the stack it gets destroyed leaving you with an invalid pointer. Dereferencing such a pointer causes many, many problems.
You should allocate the name array inside of getname on the heap, with malloc/calloc so that when you return the pointer the data won't be destroyed.
With regards to functions like strncpy, they tend to return a pointer to the resulting string; e.g.: strncpy returns a pointer to the destination.
Pointer itself represents an address, e.g. if you have a pointer typed char *pstr, you can always check the underlying address with printf("address of my pointer %p\n", pstr);
In C programming language, a string is an array of char. If you have a good knowledge of array and its memory layout, it's not too hard for you to understand c-styled string. Generally speaking, an array in C is a continuous chunk of memory with name of array represent address of the first element in the array. So is string who is a chunk of memory with name of the char array address of the first character. In addition, c-styled string terminates with character \0, so if you want to manage memory for string yourself, remember one extra byte for the tailing \0.
As to your second problem, your name in function getname is a local variable whose life time ends when function returns. However, you still want to access name outside the function which is inappropriate. You can solve this be dynamically allocated memory like in dasblinkenlight's and others' post.
Good luck.