Can you elaborate, mainly about the lethal errors part, I've read a quite a few books and tutorials that use pointer arithmetic for array manipulations and some even say that a[1] can be written as *(a + 1). This also does fit its purpose here, or I at least I think it does, I intend to write this pointer into a file eventually.
If a C function is not declared prior to being used, it is assumed to take any number of int parameters and return an int value. This is one of C's many crapnesses (C++ does not contain this particular crapness, as it's really indefensibly awful, but the first versions of pre-ANSI C did not include function prototypes, so the behaviour was in a sense unavoidable).
malloc, however, does not return int. It returns void*.
C's typing system is extraordinarily weak. It allows integers to be explicitly converted to pointers, and it allows void* pointers to be silently converted to pointers of any other type. One thing it doesn't permit, however, is the silent conversion of integers to pointers: you must use a cast. C++, in contrast, does not allow void* pointers to be converted silently; it does, however, allow the value zero to be silently converted to a pointer type. This is probably marginally worse, but whatever. We're stuck with it.
If you do not include a definition for malloc, C assumes that it returns int. An attempt to assign an int to a pointer value results in a complaint from the compiler, as such a conversion cannot be made implicitly.
However, if you cast the return value of malloc to the destination type, you'll suppress that complaint. After all, the assumed int can be explicitly converted to a pointer type without any problem.
Now, why is this a problem? It's a problem because ints and void*s are not necessarily convertible. A good example is 64-bit Windows. In 64-bit Windows, ints are 32-bit; void*s are 64-bit. If malloc is not declared, its return value is assumed to be 32-bit. If you then have an explicit cast, that 32-bit return value then gets converted somehow to a pointer value. This is bad, since it means ignoring the top 32 bits of the pointer. For small programs with small amounts of memory being allocated, that may be harmless, but for programs that use large amounts of memory, things will seem to work at first (as malloc will probably return memory below the 4 GiB barrier) but then will blow up once it returns memory above the 4 GiB limit.
On the other hand, if you do not include the cast, the compiler will tell you of the error and refuse to compile. This saves you--it will tell you "hey, this is an int, it can't be used as a pointer!" and you will fix it by letting it know that "Oh, by the way, malloc returns a void*, not an int".
So, in C, you should never cast the return value of malloc. In C++, you have no choice, but the same danger doesn't exist in C++ anyway (since C++ won't let you use functions that haven't been declared). Besides, C++ programs should in general use new.
Pointer arithmetic for array operations is safe and you are right that a[1] is exactly equivalent to *(a + 1) (and in fact, is exactly equivalent to 1[a]--addition is commutative, after all). It's just that it's much less clear to the reader. a[1] says explicitly "I have allocated an array of objects and I want to access the object at offset 1". *(a + 1) says, in contrast, "I have allocated some block of memory and want to do weird manipulations of it". It's a question of expectations.
Poll
2 (2.2%)
Author
Topic: Programming Challenges & Resources (#bay12prog) Initiative (Read 95804 times)