Reply to thread

Message: [QUOTE="David Mathog, post: 1712906"] Read the FAQ! NO address is special in C. The null pointer constant need not correspond to any address. NO address is special in C. The result of converting -1 to a pointer value is implementation-defined.[/QUOTE] So the standard says the following: 1. Pointer access to a memory block is valid when that pointer lies within that memory block or one address above it (but not one address below it). 2. There is nothing special about either address 0 (typically used as the NULL pointer, but not necessarily so) or the top of memory, or any other memory location. and real machines have the property: 3. Memory is finite. So what exactly in the ANSI standard (as opposed to each compiler's implementation of it) guarantees that the following code will work? #define DTYPE int #define ASIZE 100 DTYPE *pa; DTYPE *pp; DTYPE *plim; pa=malloc(sizeof(DTYPE)*ASIZE); if(pa){ plim = &pa[ASIZE]; for(pp=pa; pp<plim; pp++){ /* some operation on *pp */} } else { (void) fprintf(stderr,"Oops, malloc failed, exiting now...\n"); exit(EXIT_FAILURE); } If malloc returns pa such that pa[ASIZE-1] is the last int at the top of memory then the expression &pa[ASIZE] is going to resolve to something peculiar (probably 0 in most implementations) and the test pp < plim will fail on every iteration. In other words, I don't see how the C standard reconciles statement 1 (a pointer value to a memory location one unit above the allocated block is ok) and statement 2 (there are no special memory locations) with statement 3 (memory is finite). In a particular implementation I can see that this problem can be avoided by, for instance, not letting malloc or the compiler allocate a block of memory which ends exactly at the top of memory, or by using memory pointers with more range than exists in physical memory. The example above uses DTYPE just to indicate that this isn't a problem for a particular data type, it could also occur for huge structures or single characters. Unless something else prevents it, ASIZE could always be adjusted upwards until pa[ASIZE-1] fell at the top of memory and triggered the problem. And yes, I do see that recoding to this: /* check the allocated memory location, not one above it*/ plim = &(pa[ASIZE-1]); for(pp=pa; pp<=plim; pp++){ /* some operation on *pp */} avoids the test on a possibly whacky pointer value no matter where pa falls in memory. Statement 2 seems to not be entirely accurate in any case. If in some implementation malloc were to return a memory block which began with an address corresponding to the bit representation of NULL the program would exit when it checked the address returned, even though memory was allocated at that location. Presumably no extant malloc will return such a block. And that does make the memory location corresponding to NULL "special" at least to the extent that it cannot be returned by malloc, nor released by free(). Regards, David Mathog [email]mathog@caltech.edu[/email] Manager, Sequence Analysis Facility, Biology Division, Caltech [/QUOTE]

Verification