[PD-dev] [ pure-data-Bugs-2989552 ] type-punned pointers break strict aliasing rules

[SourceForge.net]

Bugs item #2989552, was opened at 2010-04-19 20:01
Message generated for change (Tracker Item Submitted) made by claudiusmaximus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2989552&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-devel
Group: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: type-punned pointers break strict aliasing rules

Initial Comment:
the current development version of Pd (well, assuming the gui-rewrite 0.43 branch is it) stiill suffers from a lot type-punned pointers that break strict aliasing rules (and would better be replaced by unions).

See here for some rationale http://lists.puredata.info/pipermail/pd-dev/2007-10/009677.html

Some command line hackery to print out some stats:
----8<----
claude at zebimus:~/code/pure-data_branches_pd-gui-rewrite_0-43$ make CFLAGS="-fstrict-aliasing -Wall" 2>&1 | grep warning.*strict | sort | sed "s|: warning.*||" | uniq | sed "s|:| |" | sort -V | ( oldsrc="none" ; while read src lineno ; do if [ $src = $oldsrc ] ; then echo $lineno ; else echo $src $lineno ; fi ; oldsrc=$src ; done ) | sed "s|\(._.*\)|;\1|" | tr "\n;" " \n" | tail -n+2 && echo
d_array.c 61 727 
d_ctl.c 110 145 327 
d_delay.c 88 
d_filter.c 72 174 305 307 390 577 810 812 
d_math.c 87 101 109 
d_osc.c 437 439 
d_soundfile.c 252 253 254 285 287 290 298 299 321 337 339 346 355 356 371 987 998 1095 1106 
----8<----
(That's a table of files with line numbers that exhibit the problem)

While replacing (*(inttype *)&floatvalue) with a (union {inttype i; floattype f; } u;) is almost trivial, it's slightly less trivial to do it the right way.

The right way involves taking into account that Pd can be now be compiled to use double instead of float, so you need a different sized inttype for each case 

The later 32bit bit-twiddling will probably break in that case anyway, so maybe better to have a compile-time check if it will work, and if not then do it the naive way...).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2989552&group_id=55736