Date:	Sun, 1 Sep 1996 11:59:09 +0400 (MSD)
From:	"Alexander V. Lukyanov" <lav AT video DOT yars DOT free DOT net>
Message-Id:	<199609010759.LAA08290@video.yars.free.net>
To:	dj AT delorie DOT com
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: long double support

> >   diffs - patch for existing files of libc
> >   ioldoubl.c - Steve Moshier's arithmetic for long doubles
> >   ld_e_cv0.c - empty conversion procedure for libc
> >   ld_e_cvt.c - wrapper for actual conversion from ioldoubl.c
> >   strtod.c - improved by Steve strtod(), it replaces old one in libc
> 
> Which of these are part of long double support, and which
> are plain bugfixes?

Well, only strtod.c can be called a bugfix. It just replaces double to
long double in strtod, thus improving precision.

> Note - some changes are to whitespace ONLY.  Please read your diffs
> and make sure you aren't making cosmetic changes anywhere.

Yes, some changes are just cosmetic, sorry. The only significant
one becides long double support is deleting of these lines in doprnt.c:
***************
*** 365,372 ****
        }
        if (flags&LONGDBL)
          CONVERT(unsigned long long) /* no ; */
-         else if(flags&SHORTINT)
-           CONVERT(unsigned short) /* no ; */
        else
          CONVERT(unsigned long) /* no ; */
  #undef CONVERT

I figured out that the assembler output for two last cases is
basically the same, thus no speed gain, just a few extra bytes of code.

> Now that I understand what's going on here, I don't like it.
> Basically, we're replicating a lot of libc functions just to deal with
> the way the linker works.  Sorry, I'm not doing this - I suspect that
> sometime in the future they'll get out of sync with libc and cause
> major headaches.

I don't like it either.

> Figure out a better way.

The only other way I see is making separate object file from
ioldoubl.c and ld_e_cvt.c. Not a nice solution too.

- Raw text -