in reply to Re^3: Defining an XS symbol in the Makefile.PL
in thread Defining an XS symbol in the Makefile.PL

Actually, what you are actually doing is probably a better option. Getting strings through varying shell quoting rules is asking for trouble.

And that leads to another option:

in Makefile.PL:

if($Config{nvsize} == 8)   { $nvbits =  64 }
elsif(length(sqrt 2) > 25) { $nvbits = 128 }
else                       { $nvbits =  80 }
$defines .= ' -DLU_NV_BITS='.$nvbits;

[download]

in XS code:

#if LU_NV_BITS == 64
#define MY_FORMAT "%.17"
#elif LU_NV_BITS == 80
#define MY_FORMAT "%.21"
#elif LU_NV_BITS == 128
#define MY_FORMAT "%.36"
#else
#error "LU_NV_BITS not set"
#endif

[download]

Passing a numeric parameter through the shell does not require quoting at all.

You could also just pass the number of digits you want, but converting that back to a string in the C preprocessor requires macro tricks documented in the GNU CPP manual.

Replies are listed 'Best First'.
Re^5: Defining an XS symbol in the Makefile.PL
by syphilis (Archbishop) on Aug 18, 2019 at 09:40 UTC
    Actually, what you are actually doing is probably a better option

    Yes, it now looks that way to me. I had no idea it would be so difficult, yet I still haven't found a way.
    q["-DMY_FORMAT=""%.16e"""] doesn't work either.

    I think it's time to give up on my initial idea and just stick with what I've got.
    Thanks for the feedback. I'll go with that variation you posted as it reads a bit better - though I don't want the #error option.
    (If LU_NV_BITS is neither 64 nor 80 then we simply set MY_FORMAT to "%.36" safe in the knowledge that it will be sufficient.)

    Update: I changed my mind and included the "#error" part of the pre-processing. It makes good defensive sense to include it.

    Cheers,
    Rob
[reply]
[d/l]

      The main reason that I included an #error directive is to catch the case where LU_NV_BITS has not been set at all.

      Also, I simply copied your probe logic, but I must ask if you are sure that that is the right way to do it. Reading a value from %Config for one test, evaluating an expression for another, and then just using a default seems strange to me. Are you sure $Config{nvsize} will not give you 10 and 16 for the 80 and 128 bit cases?

[reply]
[d/l]
[select]
        Also, I simply copied your probe logic, but I must ask if you are sure that that is the right way to do it.

        Thanks for querying - I've just now realized that I've forgotten about the DoubleDouble type of long double. (Given the amount of time I've spent puzzling over that beast, I'm actually quite appalled that I could do that !!)
        It's a case that technically should be given special handling. At the moment, the DoubleDoubles will end up in the elsif{} block, demanding a precision of "%.36" which is sufficient for the vast majority of cases ... but not all :-(
        The DoubleDouble is an nvtype that is rarely encountered and I'm tempted to leave the code as it is and just change the comment from: 
        # IEEE long double or __float128
to
# IEEE long double or __float128 or DoubleDouble

        [download]
        I'll have to do some testing on my DoubleDouble builds and look at the options.

        On recent perls the approach that I took could be replaced by examining $Config{nvtype} in conjunction with $Config{longdblkind} (when nvtype is long double).
        However, for perls prior to 5.22, $Config{longdblkind} is unavailable, so we need to use another method.
        Besides, using nvtype and longdblkind looks even messier than what I've done - though the logic is perhaps more transparent.

        The 'long double' is the type that makes things awkward - it can be either 64, 80, or 128 bits, and on 64-bit builds of perl the 80-bit, 128-bit and DoubleDouble long doubles all typically report a $Config{nvsize} value of 16, thus severely limiting the usefulness of that Config value.

        Cheers,
        Rob
[reply]
[d/l]

In Section Seekers of Perl Wisdom