Article View: comp.std.c
Article #2112Re: struct hack
From: James Kanze
Date: Sat, 10 Oct 1992 15:23
Date: Sat, 10 Oct 1992 15:23
49 lines
3168 bytes
3168 bytes
In article <1992Oct8.174101.19668@sq.sq.com> msb@sq.sq.com (Mark
Brader) writes:
> > As has also been pointed out to me in email, I made a mistake at the
> > end of my previous posting, which in fact negated most of my argument.
> >
> > The expression f->s does not have type char*, it has type char[1]. It
> > does not refer to the array returned by malloc, but simply to a small
> > part of it, the part defined in the structure.
> Hmm, I missed that too, but it doesn't affect anything. The char * value
> that we were both talking about is the one that f->s decays to as soon as
> it's used in an appropriate context. This, too, points to a single char,
> but not because the member s has a length of 1; it's because a char *
> only ever points to a single char. p only points to a single char too.
> p and the decayed f->s are interchangeable.
There is a difference. The p in my original posting pointed to a
single char *in the array returned by malloc*. The decayed f->s, on
the other hand, points to a single char in the array f->s.
The array returned by malloc has the size that was given to malloc.
Pointer arithmetic is legal as long as the pointer points somewhere
between the first char returned and the last char returned plus one.
Pointer arithmetic that would move the pointer outside of this range,
or dereferencing the pointer when it points to the last char plus one,
results in undefined bahavior, and a system is fully within its rights in
treating this as a bounds error.
The array f->s has a size of one. Pointer arithmetic is legal on this
expression as long as the resulting pointer points either to the one
char in the array, or to the char behind it. Pointer arithmetic that
would move the pointer to any other char, or dereferencing the pointer
when it points to the char behind the array, results in undefined
behavior, and a system is fully within its rights in treating this as
a bounds error.
All of the justifications for allowing this hack have been based on
the fact that the pointer was returned by malloc. This is, however,
not the case; f->s was *not* returned by malloc. It is a one char
array, which degenerates to a pointer into *this* array (and only
co-incidentally, into the array returned by malloc), and thus, the
results of accessing further char's behind the one declared are
undefined.
--
James Kanze GABI Software, Sarl.
email: kanze@us-es.sel.de 8 rue du Faisan
67000 Strasbourg
France
Technical Details
Message-ID:
<KANZE.92Oct10152357@slsvdnt.us-es.sel.de>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!ira.uka.de!slsvaat!josef!kanzeReferences:
<KANZE.92Oct2210740@slsvdnt.us-es.sel.de> <1992Oct7.001450.16021@sq.sq.com> <KANZE.92Oct7212215@slsvdnt.us-es.sel.de> <1992Oct8.174101.19668@sq.sq.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!ira.uka.de!slsvaat!josef!kanze From: kanze@us-es.sel.de (James Kanze) Subject: Re: struct hack In-Reply-To: msb@sq.sq.com's message of Thu, 8 Oct 92 17:41:01 GMT Message-ID: <KANZE.92Oct10152357@slsvdnt.us-es.sel.de> Sender: news@us-es.sel.de Organization: SEL References: <KANZE.92Oct2210740@slsvdnt.us-es.sel.de> <1992Oct7.001450.16021@sq.sq.com> <KANZE.92Oct7212215@slsvdnt.us-es.sel.de> <1992Oct8.174101.19668@sq.sq.com> Date: 10 Oct 92 15:23:57 Lines: 49