🚀 go-pugleaf

In article <1990Apr10.215213.18124@diku.dk> njk@diku.dk (Niels J|rgen Kruse) writes:
> I disagree.  It is my impression (i may be wrong), that the bounds
> of a pointer to a subobject derive from the enclosing object,
> not from the subobject itself.

I think that is probably a good idea 

> To test your model of bounds-checking in C, what are the bounds of
>         foo->buf
> after
>         struct v { int bar; char buf[1]; } *foo;
>         foo = malloc (sizeof (struct v) + 2);
> ?
> (ignoring possible allocation failure)

> Is foo->buf[2] within bounds according to your model?

My immediate reaction would be to say "no", but since X3J11 has seen fit
to allow this special case I think it would be OK for the compiler to
treat structures and arrays differently here, because the use of
substructures to refer to the whole of an extended structure has been
widespread. For another example:

	typedef struct link {
		struct link *next;
		struct link *prev;
	};

	struct foo {
		link foo_header;
		...
	};

	addlist(struct link *list, struct link *element);
	struct link *gethead(struct link *list);

	struct foo *bar;

	addlist(list, bar);

On the other hand, you *do* need to expand bounds going the other way:

	bar = gethead(list);

> Considering the disclaimers, you might choose to ignore this.

It's a tough call. I'd have been happy to go back and fix my code that
used the foo[1] convention if they'd gone the other way, I think that
just special-casing this convention would be acceptable.

> BTW, why to you have a map of Australia in your .sig? (Just curious).

I'm Australian.
-- 
 _--_|\  `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \  'U`
\_.--._/
      v