[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patches] Proposal for submission of dfp add-on to EGLIBC

On Tue, 2007-04-10 at 16:02 -0700, Jim Blandy wrote:
> Ryan, I have a question about the DFP add-on.
> As Mark said, it's important for EGLIBC's purposes that embedded
> developers be able to omit functionality they don't need, to save
> space.  DFP packaged as an add-on, as it is now, is perfect in this
> regard.  However, the add-on mechanism doesn't always lead to clean
> design: add-ons can only override entire files, and sometimes
> finer-grained changes are preferable.  I see the note on the DFP web
> page about overriding vfprintf, math.h, and so on, so it seems that
> the DFP implementation has run into this issue already.
> Would it improve things to integrate DFP directly into the GLIBC
> source tree?  If so, then EGLIBC's 'option group' mechanism would help
> you do this while still allowing embedded developers to easily omit
> decimal floating-point support if they don't need it.  The file
> 'EGLIBC.option-groups' in the top-level directory describes the option
> group mechanism in more detail.
> At the moment, there is no reflection of the selected option groups
> into C preprocessor symbol definitions, but that's something we'd be
> happy to add if it were helpful.  Option groups are a recent addition,
> and we haven't needed that behavior yet.

Hi Jim,

I agree that the override mechanism isn't desirable for obvious reasons.
It is easy enough to add a configure option to conditionally define the
relevant DFP code into the base files and I did this at one time in
early development.

Your suggested option group method has potential as well.  I'm perfectly
fine with either method.

Other than the aforementioned overridden files the dfp add-on is
non-invasive and shouldn't effect builds that don't want DFP support.

We have some due-diligence work to do before our currently unreleased
updates to libdfp are ready for inclusion into EGLIBC.  I'll keep this
mailing list posted in the coming weeks.

Ryan S. Arnold
IBM Linux Technology Center
Linux Toolchain Development