Hello!
I have uVision that compiles fine with the C51 v7.03 compiler and the related package, but not complete with the 8.06. I used two different Keil installations. All files are in the same folder.
In the 8.06 I get linker errors like "object does not fit in to pdata page" and "0080H". This looks like the compiler was thinking the PDATA was only 128 bytes, but it is set to 256 bytes in the startup.a51. Any clue what's different in the newer Keil package?
Also there is a warning in 8.06 (which does not show in 7.03) "converting non-pointer to pointer" on this
ptr_xdata = sPtr_obj->Adresse;
while the vars are set like this:
uchar uc_set_obj( uchar pdata *ptr_Set) { uchar i; uchar xdata *ptr_xdata; struct stOBJADR code *sPtr_obj; sPtr_obj=&Obj[*ptr_Set]; . . . ptr_xdata = sPtr_obj->Adresse; }
The struct stOBJADR has a member "uint Adresse;"
I can see no wrong use of the pointers. I just want to be sure that the warning does not affect the code to not work correctly.
Yes, you did: in your post of 5-Feb-2008 08:25, you wrote,
"A pointer's address for me is the address it points to."
For any other variable, "the variable's address" means the address of the variable - but you said you're using "the pointer's address" to mean the value of the pointer.
I did not!
I can only repeat, that for me a pointer's address is NOT the same as the address of a pointer. Address is defined as a target, at least in my language. So a pointer points to a target (address) and this is the pointer's address (or target). The address of the pointer, where it is located in RAM, should be pronounced as the location of the pointer.
A pointer's value for me is the value it points to. Like the address (number) in the register DPTR is the address it points to. Anything else does not make sense, since no one cares for the pointer itself, except for its data type, even if it is a pointer to a pointer.
You all may call me unteachable, but this is my way of understanding this confusing topic. Confusing because when you hear the first time about pointers (some years ago in my case), people like to confuse with the fact that a pointer points to a certain address/value, but also has an address/value, as you call it. Whereas I don't see any sense in concerning the address of the pointer itself. It just confuses...
"I did not!"
You most certainly did. The quote came from your post. It's right up there in your post that Andy referenced, recorded for history and for all to read.
"A pointer's value for me is the value it points to."
A pointer's value is an address. A dereferenced pointer yields the value addressed by the pointer.
"a pointer's address is NOT the same as the address of a pointer."
OK, maybe that's just a problem with English not being your first language - but, in English, the phrase "a pointer's address" has exactly the same meaning as the phrase "the address of a pointer"
That's nothing to do with 'C' or programming - that's the way English works.
Just as "a dog's breakfast" has the same meaning as "the breakfast of a dog"
Or "a variable's address" has the same meaning as "the address of a variable"
Or "a variable's value" has the same meaning as "the value of a variable"
Or "a pointer's value" has the same meaning as "the value of a pointer"
In general, "a thing's property" has the same meaning as "the property of a thing"
"Address is defined as a target, at least in my language"
Again, not in English.
In English, an "address" identifies a location - whether it's a postal address, that identifies the location of a house, or a memory address, that identifies the location of a particular cell within the memory array.
"So a pointer points to a target (address)"
Correct
"and this is the pointer's address (or target)."
Wrong! That doesn't even make sense by your own reasoning!
If the pointer points to any address, then that address cannot be the pointer's own address - unless the pointer is pointing to itself!
"The address of the pointer, where it is located in RAM, should be pronounced as the location of the pointer."
Correct - and "the location of the pointer" is synonymous with "the address of the pointer" which is also synonymous with "the pointer's address" which is also synonymous with "the pointer's location"
"Whereas I don't see any sense in concerning the address of the pointer itself."
Just because you don't see a need for it doesn't mean that there is no need for it!
It is also no excuse for allowing your terminology to become misleading.
You have already been given several examples of where there is a need to be concerned with it
You all may call me unteachable, but this is my way of understanding this confusing topic.
You got that backwards. It's exactly your way of thinking that renders this topic so confusing for you. It's getting in the way of your understanding it.
Your private terminology is based on firmly held, yet incorrect beliefs. Mismatch of thought with reality is the consequence. That's pretty much the definition of "confusion".
The address of an ordinary variable is generally every bit as important as its value. The same holds for pointer variables: their address is as important as their value. Pretending otherwise will bite you in the lower back soon enough.
"You all may call me unteachable"
OK then: you are unteachable; that is, in English, at least.
Maybe it'd be better if you could find someone to explain this to you in your own language?
Just think of a pointer to a pointer!
char variable; char *pointer_to_variable; char **pointer_to_pointer_to_variable;
"It just confuses"
Only because you still don't understand it, and still insist on using confusing terminology!
Or "a pointer's value" has the same meaning as "the value of a pointer
Afaik, a pointer points to a value, but it doesn't have one.
You sure? A data packet in the internet is sent to an address, the IP. Network hardware has a MAC address, where data is addressed to. If you send a letter, you send it to an address. Perhaps I should have written destination instead of target. It's sometimes not easy to distinguish between multiple words in English (target, aim, goal, destination) that have only one meaning in German (Ziel).
But still, if a pointer points to a pointer, I don't need to care about both pointer locations. This is C, so I don't care about memory addresses. This is a matter of opinion, but I don't find it very elegant to put a pointer to a pointer...
I'm also not the super programmer like you folks seem to be. I rather do many things in my life than just learning a computer language down to its deepest meaning. What counts is that it has to work. And it does! Even without non-sense warnings of a picky compiler.
You don't seem to get it. I don't understand it, because it's confusing. I can understand anything that is logical for me. Electronics, current, atoms, physics, biology down to molecules, bits and bytes. I can explain you, down to the level of an electron, how a computer works, but this is not logical to me. My terminology helps me to understand it. It's enough to know what a pointer is and does, no need to understand it.
You plainly don't understand it, and your bad terminology may well be a contributing factor to that, if not just a symptom of it.
It's not complicated.
Keep it simple and just use the same terminology as the rest of the world.
"It's enough to know what a pointer is and does, no need to understand it."
If you know what it is and does, then you really should be capable of understanding it!
Afaik, a pointer points to a value, but it doesn't have one.<p>
Well, I'm afraid your knowledge is wrong, then.
A pointer, like any other variable, has an address (where it is stored), and a value (which can be used to access a certain location in memory). A pointer does not need to point to a value.
Example:
void * some_void_ptr
some_void_ptr is a pointer. At least as far as the compiler is concerned, it does not point to a value. Hence, the compiler cannot, for example, increment it:
some_void_ptr++;
will result in an error. It also cannot dereference it:
*some_void_ptr = 0;
will also result in an error.
However, you can take the address of this pointer, for example:
void ** some_ptr_to_void_ptr; some_ptr_to_void_ptr = &some_voidptr;
This is C, so I don't care about memory addresses.
C is still way too close to the actual hardware to ignore the target platform. The C compiler will not save you from alignment faults and access penalties that stem from "not caring about memory addresses".
I rather do many things in my life than just learning a computer language down to its deepest meaning. What counts is that it has to work. And it does! Even without non-sense warnings of a picky compiler.
You are not the only one with that attitude round here.
That attitude is fine for a hobby programmer, but unfortunately is the reason why the world is full of unmaintainable, unreliable software.
Don't you mean: As Far As You Think You Know?
Pointer-to-pointer inellegant? Did you look at my strtol() example? Have you ever used strtol()?
Please suggest a more elegamnt method of knowing the position of the first invalid character in the input string.
In the general case, a function that needs to send back multiple values need to do one of the following: - Return a struct - Take a pointer to a struct as parameter, and fill in the struct. - Take multiple pointers as parameters, and update the individual parameters. - Return one value and report the other values through one or more pointers sent as parameters.
If you insist that a pointer's value is the value of the variable it points to, what value would you say a NULL pointer has? And what type si that value? If the pointer was of type pointer-to-int, is it's value then 0 or (int)NULL or what?
This is not advanced programming. The distinction between a pointer's address and it's value is what you are expected to learn during the first year if studying at a university.
It is a pre-requisite to later working with red-black trees, hash-tables, abstract data types, multi-dimensional dynamically allocated arrays etc. A real-world application may be performing just as much manipulation of a pointer as it is dereferencing the pointer, i.e. accessing the value (possibly also a pointer) that the pointer points to.
Have you tried to use qsort() to sort an array of pointers to structures? The comparison function really have to care about the level of indirection needed.
On my unix machine, the \usr\include directory contains about 1000 ** (after stripping away ** used in comments). That gives an indication that quite a lot of developers have thought that a pointer-to-a-pointer is an important concept. All these data structures and function calls does not work unless the user do care about the pointer, instead of just thinking about what it points to.
Right now, you are arguing against yourself. You are saying that you are fine with your terminology. You are saying that the important thing is that your programs works. But you are saying that pointers are confusing. If you do spend time learning the correct terminology, you will be less confused. And if you are less confused, your programs will work (even) better.
One one man stands against the world, the world is often right. The alternative is that he is a genious, and have seen the light.
Since the world has not seen the light, and have chosen to implement a huge amount of API with multiple indirection, you have to learn to accept the concept, or you will have to invent your whole world around you.
You sure? A data packet in the internet is sent to an address, the IP. <p>
No, it is not. The packet is sent to a destination. There are _two_ addresses in a packet, a source and a destination.
Network hardware has a MAC address, where data is addressed to.
The MAC of a NIC is a property of the NIC itself. It only becomes a destination/target if it is put in the right field in the network packet.
If you send a letter, you send it to an address.
A house has an address, which describes its location. It becomes a destination/target when it is written on the right part of the envelope.
So, I think that's part of the problem. You're saying "address" when you mean "destination/target", while everyone else (and all available literature) defines "address" as "location/place".
I repeat for the xth time that I absolutely KNOW what a pointer is and I also KNOW the terminology, but this KNOWLEGDE does not help me understanding it. So I just bend the terminology and then I know two terminologies, of which only my one helps me out when using pointers and describing them. Instead of telling me a thousands time, you could also just leave me have my terminology and just try to understand it for the very moment you are thinking about the pointer warning problem I actually had and then turn back to your terminology. Now you could say "why don't you turn to our terminology for a moment?". Well, I could and I did. But it didn't help. My problem is, in your terminology: if I read a value out of a struct via a struct pointer and this value is an uint value and I put this value to another pointer, also of type uint, I simply expect this procedure to be correct. The warning message C289 says "converting non-pointer to pointer". In my understanding and I guess in everyone else too, this means that I was trying to convert something that's not a pointer (a normal variable, for exmple) to a pointer. Since ptr_xdata is declared as a pointer, it will still be a pointer after its value has changed. Because the struct was formerly initialised with an address of a variable and this address turns to an uint value when stored in the location of the struct. So when reading this value I actually do the same as setting the pointer value directly to the address of the variable.