From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9607301454.AA13818@clio.rice.edu>
Subject: Re: Long double support
To: pietervk AT minf DOT vub DOT ac DOT be (Pieter Vankeerberghen)
Date: Tue, 30 Jul 1996 09:54:35 -0600 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <1.5.4.16.19960730075544.206fa44e@vub.vub.ac.be> from "Pieter Vankeerberghen" at Jul 30, 96 09:55:44 am
Content-Type: text

> Those who are doing numerical simulations need speed, memory and accuracy.

Certainly, but you need to find a way to provide those features without
a negative impact on people not needing or using those features.  

New idea - #define HIGH_PRECSION_IO before including stdio.h, and it
does the appropriate defines?  (printf/scanf/etc)

> One should have a look at the increase in code size, both in scanf and printf, 
> after compression. 

Strongly disagree, unless you plan to provide the tools to generate them
in compressed format on the fly, and automatically debug compressed images.
Why should we give back the advantages of compression, and take on the
disadvantages, just to include code in every image which is not used by
99.999% of them?

Why not just bloat libm or create a new library to provide this functionality
instead?  I'm not sure even high precision numerical simulations need
printf to be that accurate in most cases.  I may need it in the matrix
invert, but I don't care if the answers are different in th 15th decimal.

> If the code size of the hello world app is important,

No, hello world is NOT important.  But there are a bunch of programs out 
there with 10K likes of code which compile to DJGPP images less than 75K
in final size, and it doesn't make sense to bloat them all by 20% in size
for a feature not needed.