Re: cast errors reported by a OsX cmake build

[Guy Harris <guy () alum mit edu>]

On Jun 17, 2013, at 5:22 PM, Dirk Jagdmann <doj () cubic org> wrote:

> I just tried to use cmake to build current Wireshark SVN trunk source code. It fails early on with errors like:
>
> [  5%] Building C object tools/lemon/CMakeFiles/lemon.dir/lemon.c.o
> /Users/djagdmann/ws-trunk/trunk/tools/lemon/lemon.c:443:8: error: cast from 'char *' to 'struct action *' increases 
> required
>      alignment from 1 to 8 [-Werror,-Wcast-align]
>  ap = (struct action *)msort((char *)ap,(char **)&ap->next,
>       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /Users/djagdmann/ws-trunk/trunk/tools/lemon/lemon.c:457:24: error: cast from 'char *' to 'struct state *' increases 
> required
>      alignment from 1 to 8 [-Werror,-Wcast-align]
>    newaction->x.stp = (struct state *)arg;
>
> and many more of this type. Is somebody looking into cmake builds on OsX?

This isn't a cmake issue, it's a clang issue.  Clang is a bit less forgiving when it comes to playing games with 
alignment. Cmake's only contribution to the problem is that it defaults to clang (probably because it defaults to cc 
rather than gcc).

SPARC is even less forgiving, as in "your program crashes if it tries to do an unaligned load or store", so, unless we 
want to abandon support for SPARC-based machines, we should seriously consider fixing those complaints *AND*, if 
there's a gcc option to warn about those errors, turning that on to make it more likely that the build will fail if 
somebody submits code that "gee, it worked on my PC, what's the problem?"

(There may be other processors that either trap on unaligned accesses, as SPARC processors do, or do other 
non-unaligned-fetch/store things, such as ignoring the low-order bits of the address.  I think Alpha and MIPS did that. 
 Yes, PowerPC/Power Architecture processors, these days, do unaligned fetches/stores, as far as I know, and recent ARM 
processors might, but....)

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe