Re: [ft-devel] strict aliasing

[Ken Turkowski]

> On Nov 10, 2015, at 11:42 PM, Werner LEMBERG <address@hidden> wrote:
> 
>> Compilers are beginning to embrace more aggressive optimization
>> techniques.  One of these directions is that of strict aliasing.  We
>> have experienced crashes on some ARM embedded devices in some code
>> that was flagged with the “strict aliasing” warning.  We have been
>> going through our code, changing casts to unions in appropriate
>> ways, and have sidestepped the crashes.
>> 
>> However, Freetype is a bit of a problem, since it is open source.
> 
> Soo...  Do you get crashes in FreeType?

I don’t believe that we do get crashes in Freetype.

However, the code that *did* crash seemed to have things in common with bug 
#27441:
(1) a relatively large file, with 100+ APIs implemented, some which are very 
small (1-4 lines).
(2) casting of arguments passed to internal functions (not sure whether the 
crasher was static or global).
(3) liklihood that the optimizing compiler wants to inline the function called 
with casts. 

Something like:
        AFunc(const DB *db, const void **result) {
                const DirectoryEntry *dir = NULL;
                GetDirectoryEntry(db, (const void**)(&dir));
                GetData(db, dir->offset, dir->size, result);
        }

It appears that the compiler does not seem to recognize that 
GetDirectoryEntry() changes the value of dir, perhaps because it makes a copy 
of it before taking the address?

Have you reported this to the gcc team?

>> Are you planning to make a pass over the Freetype code base to
>> eradicate these strict aliases?
> 
> Well, yes, but I don't consider it urgent.  Main reason for (most of)
> the warnings is FreeType's attempt to simulate C++ classes with plain
> C.  As far as I know, we don't try to be overly clever besides
> this :-)
> 
> My preferred solution would be to use something similar to the fix in
> issue #27441, given that unions is not the right way to go for C++,
> according to advice I've seen in the internet – and I want to preserve
> the ability that a C++ compiler can compile FreeType.

It wasn’t clear what the solution was for 27441 - it seemed like it was cast to 
a different data type that has less gnarly accessors?

It is understandable that you would want to use {sub,super}classing rather than 
casting in C++. Perhaps the best solution is a SuperClassMacro(x) that reverts 
to (x)in C++ and ((union TheUltimateUnionr*)(x))->theSuperClass in the C case 
(except you need to do more testing).

>  
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=82633a2440d48ed22a1f70062d8926c37f9dcf31
> 
> [Note that for some unknown reasons this link doesn't work for me;
> maybe a Savannah bug – however, you can clone the FreeType repository
> to view the related code.]

That didn’t work for me either.

> Do you want to help here?

I am not authorized to directly contribute. However, I might be able to do some 
testing.

-Ken