(char *str) str is an unsigned 32-bit int,
is there implicit conversion ?
Code:long long i = 1;
char c = str[i];
Printable View
(char *str) str is an unsigned 32-bit int,
is there implicit conversion ?
Code:long long i = 1;
char c = str[i];
Possibly. But all you really need to do is #include <stdlib.h> and declare the type to be size_t, an unsigned integer type that is guaranteed to be large enough to hold an array index.Quote:
Originally Posted by kodax
What do you mean by this? str is a pointer to char, not an unsigned 32-bit int.Quote:
Originally Posted by kodax
Besides that, yes, you can use a 64-bit integer as an array index (as long as its value is less than the size of the array it's indexing). The compiler will automatically convert the index to whatever integer size is needed.
But size_t cannot be negative, while indexes can be negative. Perhaps ptrdiff_t would be better?Quote:
Originally Posted by Sir Galahad
The address of str has this format 0x7ffee21e5181, and it is always unsigned, but also a 32-bit integer.
The fact that address is always unsigned, index must be unsigned, no question there.
I just wanted to know if there is some sort of conversion behind the scene, if index is 64-bit.
If that is the case, at least we know that we are limited to a 32-bit range.
If you read my previous thread "bad practice - mix int and long int", there is a poster who commented, "your 64-bit machine sees the world mostly as 64-bit integers."
I just changed my entire project, limiting everything to 32-bit integer.
You can use ssize_t or intptr_t.
An address (or pointer) is not necessarily an unsigned integer; the C standards don't define an address as such.Quote:
Originally Posted by kodax
Imagine having a pointer and a negative index. This is a perfectly valid situation. Adding the two will give you an address that is lower than the base address. This code shows this sort of situation:
It doesn't matter if the index is int or long or long long (or even smaller integer types like short), as long as its value doesn't result in the address plus the index pointing outside the array, or one past the end of the array (but then you're not allowed to dereference it in that case), and as long as the integer type is large enough to hold the value of the index (you can't fit an index of 90000 in a 16-bit short, for example).Code:char alphabet[27] = "abcdefghijklmnopqrstuvwxyz";
char *p = &alphabet[26];
// indexes of various types
int i = -26;
long l = -26;
long long ll = -26;
char x;
x = p[i]; // x = 'a'
x = p[l]; // x = 'a'
x = p[ll]; // x = 'a'
ssize_t is not in standard C although it is in the POSIX standard. Strangely, it is only required to be able to represent -1 in addition to positive values.
<sys/types.h>
Quote:
Used for a count of bytes or an error indication. ... The type ssize_t shall be capable of storing values at least in the range [-1, SSIZE_MAX].
str is unsigned and n is signed, implicit conversion.
Code:*(str + n)
Again, an address (such as the address of the str array) is not unsigned (I should not have said "necessarily" in post #7--addresses are neither unsigned nor signed, full stop). It's rather pointless (ha) to say pointers are signed or unsigned.
Pointer arithmetic (adding or subtracting an offset to a pointer) has its own rules that are different from signed or unsigned integer arithmetic. For example, unsigned integers follow modulo arithmetic (the value "wraps around" like an odometer), but pointers do not follow modulo arithmetic (you can't add a value to a pointer that would cause it to wrap around--that's undefined behavior); therefore it's safe to say that addresses (in terms of the way C handles them) are not unsigned. And it's meaningless to check if a pointer is less than zero, so it's safe to say that addresses are not signed either. You also can't add two pointers together; what would the sum of two pointers even mean? (You can subtract two pointers, though, but only if both pointers point into the same object like an array or struct.)
So the most straightforward way to word it is "pointer plus offset", where pointer is neither signed nor unsigned, and offset may be signed or unsigned (since negative values are OK in some circumstances).
If you simply want the most generic way to store an offset/index in a structure, for example, use ptrdiff_t; it's signed and big enough to hold the size of any object or an index into any array (I think ptrdiff_t was designed for this purpose, among others).
Author implies that pointer is unsigned.
Quote:
Pointer Overview
You know that pointers probably have to be unsigned integers because valid virtual memory addresses can range from 0x0 to 0xffffffff. That said, it seems slightly odd when you subtract two pointers. Wouldn't a pointer need to somehow represent negative values as well? It turns out that the result of the subtraction isn't a pointer at all; instead, it's a signed integer type known as a ptrdiff_t.
Subtraction
Subtraction has similar rules to addition, except subtracting one pointer from another is permissible. When you subtract a pointer from a pointer of the same type, you're asking for the difference in the subscripts of the two elements. In this case, the resulting type isn't a pointer but a ptrdiff_t, which is a signed integer type. The C standard indicates it should be defined in the stddef.h header file.
Pointer Arithmetic | C Language Issues for Application Security | InformIT
That's one author's interpretation of matters on one specific platform. You can find a lot of writings about specific implementations (like a lot of old books about C on MS-DOS) that aren't really true in a general sense or guaranteed by C in any way.
The real question, though, is why does it matter to your application? What difference does it make? Are you doing anything with pointers in your application where their signedness matters? If you are, then it's very likely that you're doing things wrong, and any change in the compiler, compiler version, compile flags, or operating system very well may break your assumptions.
Read the c-faq on pointers for a lot of good material (unfortunately, it doesn't cover the question of pointer signedness, probably because it's not asked frequently).