C语言：将Pointer转换为String，我还能得到什么？

Question

I'm just experimenting with some system level programming using c. I have encountered something ambiguous and I'm hoping someone here can clear it up for me.

If I make a char* and then feed the address into a function in the following way

char* string;
os_IntToString(&string, string);

void os_IntToString(int value, char* str) {
    int scancode_offset = 48;

    char* start = *str;
    do{
        int piece = value % 10;
        *str++ = piece + scancode_offset;
        value = value / 10;
    } while(value);
    *str-- = '\0';
}

Then what exactly am I getting back? I get real numbers, an example would be 589796. Obviously the address is backwards but what base system is it?

Memory addresses are in hex right? But the function uses Int which is decimal base 10? Is that correct? Does a conversion process happen or do I now have a deciaml address, I just don't know.

Can anyone clear this up please. Thanks so much in advance.

Answer 1

As far as the C language is concerned, addresses are not "in hex", nor are they numbers. Addresses are just addresses, or pointer values. Depending on the addressing scheme of the system you're using, addresses might be represented in hex (for example, if printed with printf 's "%p" format). You can also convert an address to an integer, but the result of the conversion is implementation-defined -- and integers aren't "in hex" either, though you can generate a human-readable hexadecimal representation of an integer. (Integers are represented in binary.)

As for your function, you've defined it with a void return type, and then attempted to return a char* value from it. You should have gotten at least a warning from your compiler, if not a fatal error.

Answer 2

All data (memory addresses, ints, pointers, strings, floats, etc) are internally stored as binary, or base 2.

Being base 10 or base 16 is not a question of how the hardware or software (libc, your program, the assmebly, or even CPU microcode) stores and manipulates it (except for binary-coded decimal which is rarely used except for certain display and conversion steps).

When you are returned an int, while you assume it as base 10(and most calls that will print the int display it as base 10), for the hardware it holds its meaning as base 2, the same as the pointer or memory address. It just gets printed that way.

Moreover, for the memory address, base 2 is only due to the way the circuits operate in the CPU and northbridge. When you see it as base 16, it's just the debugger's representation. We could hypothetically address it as base 10 and refer to 65536 in memory but it is just easier to use 10000 for display as trailing zeroes help clue the programmer into the alignment. It's just a convenient representation. We could use base 13 and call it 23AA3 but that would simply be inconvenient. When we see it as a number, it is not necessarily a number. It is a location, and while in certain respects it could be considered a number, and it is convenient for the programmer to see it as a number, the nonlinear nature of memory mapping on today's systems can make that consideration somewhat incorrect.

While there may be problems with the code itself I'm simply answering the point of number representation.

Answer 3

The address isn't backwards. Printf shoudl always print big endian. If you print the address locations, if you get 589796 when an int, if you print it as hex, then you'll get 0x8FFE4 = 589796. Everything is working as it should, since no matter hwo you print it, its going to be the correct memory address, just with a different representation.