Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<62o1en$9em@mulga.cs.mu.OZ.AU>...

> [Deleted]

I agree with what you said above.

>  char buf[sizeof(int)];
>  int *p = (int *) buf;
>  if (p) *p = 42;
>
> is not well-defined, because there is no guarantee that the address
> is suitably aligned.

However this example is not well defined even if all (explicit) alignment
restrictions were removed from the standard.  From 3.10 para 15:

"If  a program attempts to access the stored value of an object through an
lvalue of other than one of the following  types  the  behavior  is
undefined"

Here you are trying to access the stored value of 'buf' through '*p', and
'int' is not an acceptable type for modifying char[n].  (I'm assuming that
changing the stored value is a form of access).

It is likely that one of the reasons for the rule (3.10[15]) was alignment.
 However there were undoubtedly others (a footnote mentions aliasing
concerns).

A place where the standard would be different without alignment discussions
is in user-defined new().  The standard says such functions must return
suitably aligned memory but doesn't say how to tell if memory is suitably
aligned.  In practice this means that a portable user-defined new() must be
implemented in terms of either the implementation's new or in terms of
malloc(), being carefull to preserve alignment.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Bill Wade <bill.wade@stoner.com> writes:

> >  char buf[sizeof(int)];
> >  int *p = (int *) buf;
> >  if (p) *p = 42;
> >
> > is not well-defined, because there is no guarantee that the address
> > is suitably aligned.

> However this example is not well defined even if all (explicit) alignment
> restrictions were removed from the standard.  From 3.10 para 15:
>
> "If  a program attempts to access the stored value of an object through an
> lvalue of other than one of the following  types  the  behavior  is
> undefined"

But my understanding is that you can't get such a lvalue, so
this para seems useless to me. In particular, I don't why
'int *p = (int *) buf;' should construct a pointer of type int*
to buf (at least in C++, the wording about reinterpret_cast
doesn't say that).

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]