Re: [patches] Fw: What license is acceptable for libdecnumber

[Jim Blandy <jimb@xxxxxxxxxxxxxxxx>]

"Ryan S. Arnold" <rsa@xxxxxxxxxx> writes:
> On Tue, 2007-09-18 at 13:43 -0700, Jim Blandy wrote:
>> "Ryan S. Arnold" <rsa@xxxxxxxxxx> writes:
>> > I agree.  We intend to incorporate the code in the existing overrides
>> > into the base files using conditionals.
>> >
>> > Jim do you want patches to the base files to accompany the initial
>> > libdfp patch or can we provide a patch at a later time to eliminate the
>> > overrides and add the conditionalized code to the base files?
>> 
>> The patches to the base files probably should be in the initial patch.
>> Exactly how the generic code adapts to DFP's presence and absence
>> would seem to me to be the most interesting thing to review.
>
> The ISO C-spec technical report defines two macros:
>
> __STDC_DEC_FP__ indicates conformance to the technical report.
>
> __STDC_WANT_DEC_FP__ indicates the desired inclusion of particular
> decimal floating point features provided by headers.
>
> I think __STDC_DEC_FP__ can be used to conditionally include/exclude
> code from being built into the shared libraries whereas
> __STDC_WANT_DEC_FP__ is a user specified define which indicates that
> decimal float prototypes are a desired features of the included header
> file.

Joseph Myers had some thoughts on how best to do this when it came up
last year: http://www.eglibc.org/archives/patches/msg00012.html

Does __STDC_DEC_FP__ get defined by GCC, or by glibc with the dfp
add-on?  I would assume glibc+dfp would be the best place, as that's
where things required by the TR like FE_DEC_TOWARDZERO and strtod128
come from; only the C library is in a position to know whether the
TR's full facilities are available.  However, I don't see any such
definition there, so I'm confused.

It seems to me that we want code included in GLIBC shared libraries to
be present based on positive information that the add-on is present
and enabled; if __STDC_DEC_FP__ is to be defined by GLIBC/libdfp, then
that would work.

If glibc is to define __STDC_DEC_FP__, is there a particular
identifier (like __DECIMAL_BID_FORMAT__ or __DECIMAL_DPD_FORMAT__)
that glibc+libdfp should test to make sure the compiler has the
necessary support?  I see a libdfp configure-time test for this
commented out.

> One thing I haven't considered is the logistics of gracefully denying a
> user's request of decimal float support (specified with
> -D__STDC_WANT_DEC_FP__) when libc has been built without
> -D__STDC_DEC_FP__.

Would that be more complicated than adding an #ifndef __STDC_DEC_FP__/
#error inside the #ifdef __STDC_WANT_DEC_FP__ clause in the DFP
math.h?

> As it currently stands they'd simply get undefined references to certain
> decimal-float-only functions on link and at worst they'd experience
> failed function calls due to unrecognized types (e.g. for printf support
> when they ask for _Decimal128 printing using %DDf).

We'd certainly like to get a static error whenever possible. :)