Re: [Lit.] Buffer overruns

From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 01/17/05 

Date: Mon, 17 Jan 2005 09:50:22 -0500
To:  brg@nowhere.org

BRG wrote:
> So we need Doug to tell us which is correct (maybe neither - is it
> undefined behaviour?). Doug?

For reference the code being discussed is:

#include <stdio.h>
typedef char ctype[100];
int main()
{ char x[100], *y;
   ctype c;
   printf("\n%3d %3d", sizeof(x), sizeof(&x));
   printf("\n%3d %3d", sizeof(y), sizeof(&y));
   printf("\n%3d %3d", sizeof(c), sizeof(&c));
   return 0;
}

First note that %d is wrong, since the type of the result of
sizeof isn't int nor even necessarily unsigned int (which
would be punnable with int in this context). So let's
assume that every sizeof result is immediately cast to int.

Next note that the sizes of pointers vary, and aren't
necessarily all the same size within an implementation.
However, for purposes of this discussion everybody seems
to be assuming an implementation with 4-byte pointers.

Further note that there are two kinds of sizeof, one
for type names (requiring parentheses) and one for objects
(not requiring parentheses). Fortunately, the redundant
parentheses do not affect the types of the operands of sizeof.

Finally note that the final text-output line does not end
with a new-line and thus might not actually appear. Let's
assume this is fixed.

Under the above pointer-size assumption, the output required
for conformance with the C standard would be:

100 4
   4 4
100 4

I.e., the address of an array is a pointer to an array
(note: *not* a pointer to the first element of the array),
not the array itself. Although not shown in the example
program, in most expression contexts (operand of & and
operand of sizeof being exceptions) an array gets
automatically converted to a pointer to the fist element of
the array. I don't know how any C compiler produced after
1988 could get any of this wrong; the rules are quite clear.

I suspect the reported compiler that produced different
results dates back to before the C standard and was never
thoroughly updated; before the standard, &array sometimes
didn't have the meaning it now has for Standard C.

Relevant Pages

  • Re: Warning on assigning a function-returning-a-pointer-to-arrays
    ... This declares pfunc as a function taking no arguments and returning ... int x, y; ... Presumably pfuncwill return a pointer to a single int, ... or the first of a sequence of "array 5 of int"s. ...
    (comp.lang.c)
  • Re: problem with memcpy and pointers/arrays confusion - again
    ... int line, unsigned long *total_mem) ... That's a long pointer address... ... If sizeof > sizeof which is ... if you allocate for char with sizeof < sizeof, ...
    (comp.lang.c)
  • Re: Newbie
    ... to talk about the int value 3 and the int value 4, ... It also lets you talk about pointer ... C has a special rule for array objects. ... to printf() is: ...
    (comp.lang.c)
  • Re: union {unsigned char u[10]; ...}
    ... But character type is not a union. ... u.a is of type int. ... has to do so to make pointer equality work consistently). ... were a single-element array. ...
    (comp.lang.c)
  • Re: union {unsigned char u[10]; ...}
    ... But character type is not a union. ... u.a is of type int. ... has to do so to make pointer equality work consistently). ... were a single-element array. ...
    (comp.lang.c)