A good portion of the problem may be GCC's optimization routines. As
the -O level rises, the compiler makes assumptions about things like
pointers which are more strict than the standard requires.
Unfortunately, these routines can become confused unless your code is
laid out very explicitly.

I think most backends do manual manipulation of char arrays. Look at
fujitsu-scsi.h for instance.

allan

On Sat, Jan 22, 2011 at 5:54 AM, Reinhold Kainhofer
<reinhold at kainhofer.com> wrote:
> Am Donnerstag, 20. Januar 2011, um 21:26:42 schrieb m. allan noah:
>> What if you make the pointer unsigned char instead?
>
> If I use "unsigned char*", then I get no warning. However, I fail to see why
> using an additional variable makes a difference...
>
> This does not work (&b[0] is a pointer to an unsigned char, right?):
> ? unsigned char b[4];
> ? htole32a(&b[0], value);
>
> while this does:
> ? unsigned char b[4];
> ? unsigned char *bp=&b[0];
> ? htole32a(bp, value);
>
> Anyway, I have a local patch that gets rid of all the byteorder.h macros and
> instead copies all little-endian encoded values manually byte-by-byte. I'm
> currently away from home, so I cant test it with my magicolor scanner. I'll
> commit it as soon as I'm back home (probably tomorrow).
>
> Sorry for the breakage!
> Reinhold
>
> --
> ------------------------------------------------------------------
> Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
> ?* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
> ?* http://www.fam.tuwien.ac.at/, DVR: 0005886
> ?* LilyPond, Music typesetting, http://www.lilypond.org
>



-- 
"The truth is an offense, but not a sin"

Reply via email to