Subject: Re: [linux-audio-dev] sfront 0.65 09/07/00
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Fri Sep 08 2000 - 23:37:52 EEST
> From iain_AT_sandoe.co.uk Fri Sep 8 02:28:16 2000
[...]
> - that is I think it's a byte ordering problem - not an embedded 0 problem
> (but maybe I'm not awake yet :-)
>
> [or maybe you re-reverse it at run-time]
I think it re-reverses, and that it's not byte-order related --
primary evidence is that gcc running under Solaris handles the
hexadecimal string encoding just fine, while cc under Solaris
produces a binary that crashes on takeoff. Another reason I
think its the "embedded \x00" issue is that I'm only using the
trick on float arrays, and I had thought IEEE floating-point
didn't have machine-specific byte-order issues (maybe I'm wrong
on that).
In any event, by default sfront produces the slow
float foo[1] = { 0.39485};
initialization, and only uses embedded strings if the -hexdata
flag is selected ...
--jl
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Sat Sep 09 2000 - 00:41:04 EEST