🚀 go-pugleaf

Steve Clamage (clamage@Eng) wrote:
|> In article 14306@nlm.nih.gov, bkline@cortex.nlm.nih.gov (Bob Kline) writes:
|> >
|> >I have found (on more than one occasion) published code which
|> >appears to rely on an assumption about c++ for which I haven't 
|> >been able to find any justification in the ARM or the draft
|> >standard itself.  The assumption is that a static array of
|> >char is guaranteed to be suitably aligned to hold objects of
|> >any types overlaid on the array's space.  Here is an example
|> >from James Coplien's "Advanced C++ Programming Styles and
|> >Idioms" (page 149, ff.):
|> >
|> >    unsigned char bigBuf[4096], *bigBufPtr = bigBuf;
|> >
|> >    class LAPD {
|> >    public:
|> >        void *operator new(size_t) { return (void *)bigBufPtr; }
|> >        ...
|> >    };
|> >
|> >The details of the class are elided here, but several pages later
|> >the data members are shown to include a couple of pointers, which
|> >(at least on some machines with which I am familiar) would cause
|> >things to blow up if they were not placed on a suitably aligned
|> >memory boundary.
|> >
|> >So my question is: does the draft standard require that all arrays
|> >of char be placed by the compiler at an address which would meet
|> >the alignment requirements for any object which might be placed
|> >there?  If so, where should I look in the draft to find this
|> >requirement?

|> An array of char must be suitably aligned for access to the char elements.
|> I don't believe there is any requirement that it be suitably aligned for
|> any other type. For this kind of general usage, I think you have to use an
|> array element type corresponding to worst-case alignment requirements.

In fact, I think that there are compilers in actual existance which do
allocate such arrays on unaligned addresses.

There was a thread concerning this a year or two ago, but with dynamic
memory.  If memory serves me right, the consensus was also that a new
expression does not guarantee alignment either, but that a direct call
to the operator new function did (a la malloc).

|> For example, if long double has the severest alignment requirements (as on
|> the Sparc), you should write for example
|>  long double bigBuf[4096/sizeof(long double)];
|>  void* bigBufPtr = bigBuf;

|> It is a requirement that the space returned by operator new be suitably
|> aligned for any object of the requested size. The sample code probably works
|> on many systems, but I don't think the standard allows you to assume so.

Somewhere in my machine dependancy file, I define a union:

    union GB_MaxAlignment
    {
        long                l ;
        double              d ;
        void*               p ;
        void              (*pf)() ;
    } ;

As its location indicates, it is ``machine dependent'', although I've
yet to find a machine where the above declaration didn't do the job.
The static declaration then becomes:

    union
    {
        unsigned char       buffer[ n * sizeof( X ) ] ;
        GB_MaxAlignment     dummyForAlignment ;
    }                   data ;

    new ( data.buffer ) X[ n ] ;

In defence of Jim Coplien, I'm too lazy to look up the exact example,
but from the name (LAPD), I'd guess that this is a class whose data will
be read from or written to an external source, and which because of
this, will only contain byte data anyway.  (LAPD is the name of the
layer two protocol in the OSI protocol suite.)  If this is the case, his
example should work anyway.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]