[pdal] Alignment issues of getField and friends

Michael P. Gerlek mpg at flaxen.com
Wed Oct 5 12:52:37 EDT 2011


The general problem is we've got an array of bytes from which we're extracting out an int, and there's no assurance that the int happens to be 4-byte aligned.

The Right Thing To Do would be to make sure that our schemas get constructed with proper alignment.  That is, every time we append a Dimension to the schema, we add the needed padding to make sure each type lies on its natural boundary -- and when we allocate a PointBuffer it should be aligned to the largest such boundary.

(And even then, I'm not sure how to tell the compiler that we know we're safe in these cases, short of a #pragma.)

On the x86, of course, it doesn't matter, so I'd prefer not to worry about it.  But on the other hand I'm very fussy about stomping compiler warnings too...
-mpg



> -----Original Message-----
> From: pdal-bounces at lists.osgeo.org [mailto:pdal-bounces at lists.osgeo.org] On Behalf Of Howard Butler
> Sent: Wednesday, October 05, 2011 7:54 AM
> To: pdal at lists.osgeo.org
> Subject: [pdal] Alignment issues of getField and friends
> 
> Michael,
> 
> I was testing out compiling PDAL with clang and it throws a number of cast alignment warnings related to our templated getField calls:
> 
> > In file included from /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:35:
> > /Users/hobu/dev/git/pdal/src/../include/pdal/PointBuffer.hpp:239:13: warning: cast from 'boost::uint8_t *'
> >       (aka 'unsigned char *') to 'short *' increases required alignment from 1 to 2 [-Wcast-align]
> >     return *(T*)p;
> >             ^~~~~
> > /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:198:31: note: in instantiation of function template specialization
> >       'pdal::PointBuffer::getField<short>' requested here
> >                     output += STRINGIFY(GETFIELDAS(boost::int16_t));
> >                               ^
> > /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:198:41: note: instantiated from:
> >                     output += STRINGIFY(GETFIELDAS(boost::int16_t));
> >                                         ^
> > /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:173:23: note: instantiated from:
> > #define GETFIELDAS(T) getField<T>(pointIndex, fieldIndex)
> >                       ^
> > In file included from /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:35:
> > /Users/hobu/dev/git/pdal/src/../include/pdal/PointBuffer.hpp:239:13: warning: cast from 'boost::uint8_t *'
> >       (aka 'unsigned char *') to 'unsigned short *' increases required alignment from 1 to 2 [-Wcast-align]
> >     return *(T*)p;
> >             ^~~~~
> > /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:208:31: note: in instantiation of function template specialization
> >       'pdal::PointBuffer::getField<unsigned short>' requested here
> >                     output += STRINGIFY(GETFIELDAS(boost::uint16_t));
> >                               ^
> > /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:208:41: note: instantiated from:
> >                     output += STRINGIFY(GETFIELDAS(boost::uint16_t));
> >                                         ^
> > /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:173:23: note: instantiated from:
> > #define GETFIELDAS(T) getField<T>(pointIndex, fieldIndex)
> >                       ^
> > In file included from /Users/hobu/dev/git/pdal/src/PointBuffer.cpp:35:
> > /Users/hobu/dev/git/pdal/src/../include/pdal/PointBuffer.hpp:239:13: warning: cast from 'boost::uint8_t *'
> >       (aka 'unsigned char *') to 'int *' increases required alignment from 1 to 4 [-Wcast-align]
> >     return *(T*)p;
> 
> 
>  http://stackoverflow.com/questions/2741787/warning-cast-increases-required-alignment has something to say about this, but the
> memcpy has the potential to be a performance killer unless the implementation is smart in some way. These alignment issues would
> be real if we were to move to a Power7 or something (not outside the realm of possibility for this kind of software/problem domain).
> What should we do?
> 
> Howard_______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal



More information about the pdal mailing list