Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!dkuug!freja.diku.dk!njk
From: njk@diku.dk (Niels J|rgen Kruse)
Newsgroups: comp.lang.c
Subject: Re: Array bounds checking with C????
Message-ID: <1990Aug30.134537.26326@diku.dk>
Date: 30 Aug 90 13:45:37 GMT
References: <7611@ucdavis.ucdavis.edu> <869@qmfl.jrdc.go.jp> <425@taumet.com>
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 32

steve@taumet.com (Stephen Clamage) writes:

>There is nothing to prevent the C compiler from carrying around enough
>information with arrays and pointers to detect those problems at runtime
>which cannot be found at compile time.  (...)
>if possible, at run time otherwise.  This approach is in fact implemented
>in some compilers.
>--

Oh.  Which ones?

Assume the following code:

        char *a,*c; double *b,d[17/sizeof(double)];

        if (a = malloc (17)) {
          b = (double *)a;
          c = (char *)b;
          /*  A  */
        }

At location A, a[16] is of course legal and a + 17 is
computable but not dereferenceable.  Also, it is obvious that
b[17/sizeof(double) - 1] is legal and b + 17/sizeof(double) is
computable but not dereferenceable.  But what about c?
Is c[16] legal?  Note that c[16] does not constitute part of
any double within bounds of b (unless sizeof(double) == 17 or 1).
What kind of object is b pointing to?  How does it differ from
the object pointed to by (d+0)?

What does your bounds-checking C compiler have to say?
What does the standard say?
-- 
Niels J|rgen Kruse 	DIKU Graduate 	njk@diku.dk