🚀 go-pugleaf

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.

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.
---
Steve Clamage, stephen.clamage@eng.sun.com



[ 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. ]

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. ]

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.

Such code is neither strictly conforming nor portable.

>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?

No, it does not.  Nor is the final version of the C++ standard likely to.

There is currently NO strictly conforming way of doing this, although
there is a portable way.  The portable way is as follows.  First,
define a type MaxAlign that has maximal alignment.  (This is the part
that can be done portably, but not strictly conformingly.)  Second,
instead of using just a plain static array of characters, use an
anonymous union with MaxAlign:

	union {
		MaxAlign dummy_union_member_to_force_alignment;
		char bigBuf[4096];
	};
	
To define the type MaxAlign, use a union of all the types that might
possibly have difficult alignment requirements:

	/* A type with the maximum alignment requirents */
	typedef union {
	  long i;		/* integer */
	  void *p;		/* pointer */
	  double d1;		/* floating point */
	  long double d2;
	  void (*f)(void);	/* function pointer */
	} MaxAlign;

The problem is that there is no standard-conforming way of guaranteeing
that MaxAlign really does have the maximum alignment requirement.

It has been suggested (by myself, and also others) that a `MaxAlign'
(or `max_align_t', as it would probably be called if it were
in the implementation's namespace) type should be added to the standard
library, to allow a standard-conforming way to write code like the
example in Coplien that you quoted.  This is currently still on one of
the committee's "open issues" lists.

-- 
Fergus Henderson             |  #define x t=a[i],a[i]=a[m],a[m]=t
                             |  char a[]=" 12345678";main(m,i,j,t){for(i=m;i<
fjh@cs.mu.oz.au              |  9;x,i++)for(x,j=m;--j?(t=a[m-j]-a[m])-j&&t+j:
http://www.cs.mu.oz.au/~fjh  |  main(m+1)*0;);m-9||puts(a+1);} /* 8 queens */

[ 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. ]