[Numpy-discussion] Solaris Sparc build broken
David Cournapeau
david at ar.media.kyoto-u.ac.jp
Fri Nov 6 02:10:58 EST 2009
Charles R Harris wrote:
>
>
> On Thu, Nov 5, 2009 at 10:35 PM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp <mailto:david at ar.media.kyoto-u.ac.jp>>
> wrote:
>
> Charles R Harris wrote:
> > So you are going to leave us all hanging here in curiosity? What is
> > your solution?
>
> I had to sleep :)
>
> The solution is based on parsing the generated binary code -
> that's how
> MPFR is doing it, so it has been tested in the wild. The code to
> compile
> is something like:
>
> /* "before" is 16 bytes to ensure there's no padding between it
> and "x".
> * We're not expecting any "long double" bigger than 16 bytes
> or with
> * alignment requirements stricter than 16 bytes. */
> typedef long double test_type;
>
> struct {
> char before[16];
> test_type x;
> char after[8];
> } foo = {
> { '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0',
> '\001', '\043', '\105', '\147', '\211', '\253', '\315',
> '\357' },
> -123456789.0,
> { '\376', '\334', '\272', '\230', '\166', '\124', '\062',
> '\020' }
> };
>
> They compile it, parse with awk from the dump od -f.
>
>
> So the before/after bits are tags that mark the beginning/end of the
> type for the parse? Any particular reason not to use a string?
As for why not using my name, I am not that megalomaniac, at least not
yet :)
od prints a dump in octal form, so a string is not much more readable. I
am not sure why they use od instead of another dump format - but there
is value if keeping the same format as them for testing, all other
things being equal.
Anyway, the detection code is checked in in svn now, I just need to fix
universal build issue, but this should not be difficult,
David
More information about the NumPy-Discussion
mailing list