Re: [Cobolforgcc-devel] Cleaned Decimal / Binary routines

[Tim J. <te...@me...>]

"Theodore J. Seward, Jr." wrote:
> 
> Tim,
> 
> I think I have the file names all cleaned up as you requested.  The compile options have all the requested warning checks.  I've gone through and removed all warnings.  Even as I send this I notice there are inconsistencies in the readme file.
> 
> Good Luck  - Ted Seward
> 
>               Decimal / Binary Conversion Routines
>               ------- - ------ ---------- --------
> 
> The following routines are provided by these files:
> 
>    Packed Decimal to:
> 
>       Signed 16 bit binary    cobr_dtb_INT16
>       Unsigned 16 bit binary  cobr_dtb_UINT16
>       Signed 32 bit binary    cobr_dtb_INT32
>       Unsigned 32 bit binary  cobr_dtb_UINT32
>       Signed 64 bit binary    cobr_dtb_INT64
>       Unsigned 64 bit binary  cobr_dtb_UINT64
>       Signed 128 bit binary   cobr_dtb_INT128
>       Unsigned 128 bit binary cobr_dtb_UINT128
> 
>    Packed Decimal from:
> 
>       Signed 16 bit binary    cobr_btd_INT16
>       Unsigned 16 bit binary  cobr_btd_UINT16
>       Signed 32 bit binary    cobr_btd_INT32
>       Unsigned 32 bit binary  cobr_btd_UINT32
>       Signed 64 bit binary    cobr_btd_INT64
>       Unsigned 64 bit binary  cobr_btd_UINT64
>       Signed 128 bit binary   cobr_btd_INT128
>       Unsigned 128 bit binary cobr_btd_UINT128
> 
>    Validation:
> 
>       Validate Packed Number  cobr_validate_packed
> 
> Several problems arose while I was coding these routines, which I
> now think are fixed:
> 
> *  My PC at home is only capable of 32 bit binary.  When I
>    display the size of long, I get 4 bytes.
> 
> *  The GNU C compiler does not even support type "long long",
>    i.e. 128 bit binary.
> 
> *  The code for each version (16, 32, 64, 128) was so close,
>    except for a few constants and data types, that any maintenance
>    would likely skip one of the types.
> 
> *  The 2**128 is a large number exceeding compiler limits, e.g.
> 
>     128
>    2    = 340,282,366,920,938,463,463,374,607,431,768,211,456
> 
>    but
> 
> The problems were solved as follows:
> 
> *  While I could not test the 64 or 128 bit versions, I could
>    make sure that they used the same logic path as 16 and 32 so
>    that the chance of failure would be low since the paths were
>    already tested.
> 
>    This was done by placing all the code in a single header file
>    (cobr_decbinxx.h) with macro symbols for the routine names and
>    for any type specific constant.  For each routines, e.g.
>    cobr_decbin32.c, the source member would set symbols for the
>    routine names, data types, and data width prior to including
>    the header file.
> 
>    The header file, has some conditional tests at the top which
>    will set the constants for the given type based on the width
>    of the type (set in the file including it).  This stops any
>    warnings or errors caused by a hard coded constant that the
>    machine does not support.  For example (The actual source code
>    has comments not included in this example):
> 
> 
>    +----------+
>    | config.h |
>    +----------+
> 
>     ...
>    #define INT32       int
>    #define UINT32      unsigned int
>    #define INT32_WIDTH (4)
>     ...
> 
>    +---------------+
>    | cobr_decb32.c |
>    +---------------+
> 
>     ...
>    #include "config.h"
>     ...
>    #define INT_WIDTH     INT32_WIDTH
>    #define INT_BTD_NAME  cobr_btd_INT32
>    #define INT_DTB_NAME  cobr_dtb_INT32
>    #define INT_HANDLER   cobr_INT32_handler
>    #define INT_TYPE      INT32
>    #define UINT_BTD_NAME cobr_btd_UINT32
>    #define UINT_DTB_NAME cobr_dtb_UINT32
>    #define UINT_HANDLER  cobr_UINT32_handler
>    #define UINT_TYPE     UINT32
>     ...
>    #include "cobr_decbxx.h"
> 
>    +---------------+
>    | cobr_decbxx.h |
>    +---------------+
> 
>     ...
>    #elif INT_WIDTH == 4
>    #define INT_MAXCHAR       (10)
>    #define INT_MAXPOS_CHAR   "2147483647"
>    #define INT_MAXNEG_CHAR   "2147483648"
>    #define INT_MAXNEG_BIN    (-2147483647-1)
>    #define INT_MAXNEG_PACK   "\x02\x14\x74\x83\x64\x8D"
>    #define INT_MAXNEG_PACKL  (6)
>    #define UINT_MAXCHAR      (10)
>    #define UINT_MAXPOS_CHAR  "4294967295"
>    #elif INT_WIDTH == 8
>     ...
>    void
>    INT_BTD_NAME (INT_TYPE *  binary,
>               int         decimal_length_in_bytes,
>               void *      decimal_value,
>               INT_HANDLER ErrorRout)
>     ...
> 
> *  The same problems struct the test driver.  At the top of
>    test_decbin.c, there are some similar tests to define the test
>    data based on the current widths of INT64 and INT128.
> 
> *  A special note is needed here for the INT128 type, since there
>    is no support for it at this time in the gcc compiler, nor did
>    I find it in my ANSI C manuals, I could not find out what type
>    qualifier to place after the constants.  Once the compiler has
>    support for this, these lines will have to change.  See the
>    warnings at the top of the following two files and make the
>    described changes:
> 
>    cobr_decbxx.c
>    test_decbin.c
> 
> *  If this code is to execute on a machine that supports long as
>    an 8 byte value and/or long long as a 16 byte value, then you
>    will need to adjust file config.h.  See the warnings at the
>    top of that file.
> 
>                          Name: cobr_decbin.tar.gz
>    cobr_decbin.tar.gz    Type: Unix Tape Archive (application/x-tar)
>                      Encoding: base64