Files
TeslaRel410/BORLAND/BC45/SOURCE/RTL/RTLINC/COMMON16/FAKEIEEE.H
T
CydandClaude Fable 5 63312e07f9 source410: literal 4.10 source reconstruction + BC++ 4.52 fleet toolchain archived
- BORLAND/: Borland C++ 4.52 (chosen over 4.5 by byte-match: CODE/RP/CW32.LIB
  is identical to 4.52's install lib). BCC32/TLINK32/TLIB/MAKE run natively on
  Win11; CODE/BT/OPT.MAK is the shipped BTL4OPT.EXE's exact flag recipe
  (extender = Borland PowerPack DPMI32, not Phar Lap TNT).
- restoration/source410/: the literal 1995-form reconstruction of the missing
  BT game source (never mixed into CODE/). Round 1-3 state:
  * 6 of 10 surviving original TUs COMPILE CLEAN under the period toolchain
    (BTMSSN, BTCNSL, BTSCNRL, BTTEAM, BTL4MODE, BTL4ARND) - first builds
    since 1996.
  * BT_L4/BTL4APP.CPP pilot reconstruction: 12/12 functions, Fail() lands on
    its binary-recorded line 400 exactly.
  * BT/BTCNSL.HPP: console wire IDs recovered from the binary's ctors
    (Killed=9, Damaged=10, ScoreUpdate=13, DeathWithoutHonor=15 [T1];
    TeamScore=12 flagged [T4]).
  * MUNGA/: 8 engine-header backfills back-dated from the BT412 WinTesla tree
    (VDATA numbering decomp-verified; AUDREND's OpenAL-era virtual removed -
    the period compiler is the drift detector).
  * Tooling: backdate.py (WinTesla->1995 header transform), compile410.sh
    (per-TU verification sweep under authentic OPT.MAK flags).
  * README: corrected roadmap - MECH.HPP is the capstone grown with the mech
    TU reconstructions; BTREG.CPP green = the header-family milestone.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-19 07:33:26 -05:00

73 lines
2.5 KiB
C++

/*------------------------------------------------------------------------
* filename - fakeieee.h
*
* fake IEEE floating point package interface
*-----------------------------------------------------------------------*/
/*
* C/C++ Run Time Library - Version 6.5
*
* Copyright (c) 1991, 1994 by Borland International
* All Rights Reserved.
*
*/
/*
If you do not have the IEEE-recommended functions discussed in
file ostreamf.c, and if any of these statements is true
(a) Your system does not use IEEE floating-point.
(b) Your system doesn't have Infinity or Not-A-Number.
(c) Your system won't generate runtime aborts on overflow,
Infinity, or Not-A-Number (NaN).
(d) You don't care about runtime aborts in stream I/O.
then you may use these simple definitions to get ostreamf.c up and
running quickly.
Here we assume:
(1) There is no special representation for Infinities.
(2) There is no such thing as Not-A-Number (NaN).
*/
// The following define the kinds (classes) of a floating-point number
#define FPSIGNAN 0 // signaling NaN
#define FPQUIETNAN 1 // quiet NaN
#define FPNEGINF 2 // -infinity
#define FPNEG 3 // negative normalized nonzero
#define FPNEGDENOR 4 // negative denormalized
#define FPNEGZERO 5 // -0
#define FPPOSZERO 6 // +0
#define FPPOSDENOR 7 // positive denormalized
#define FPPOS 8 // positive normalized nonzero
#define FPPOSINF 9 // +infinity
/* Returns kind (class) of parmeter.
* We assume only positive, negative, or zero is possible.
* This function is pretty inefficient, but we make no assumptions
* whatever about floating-point representation.
*/
fpclass(long double d)
{
return (d < 0.0) ? FPNEG : ((d == 0.0) ? FPPOSZERO : FPPOS);
}
/* True if parameter is a NaN.
* We assume there is no such thing as a NaN.
*/
inline int fpisnan( long double ) { return 0; }
/* True if -inf < parameter < inf.
* We assume there are no infinities.
*/
inline int fpfinite( long double ) { return 1; }
/* Return the first value with the sign of the second,
* even if one is Infinity or a NaN.
* This function is pretty inefficient, but we make no assumptions
* whatever about floating-point representation.
*/
long double fpcopysign( long double d1, long double d2 )
{
return ( d1 && ((d1 < 0.0) != (d2 < 0.0)) ) ? -d1 : d1;
}