Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sftig.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!mhuxm!sftig!danny
From: danny@sftig.UUCP (L.Rosler)
Newsgroups: net.lang.c
Subject: integer division in ANSI C
Message-ID: <695@sftig.UUCP>
Date: Tue, 25-Feb-86 21:58:02 EST
Article-I.D.: sftig.695
Posted: Tue Feb 25 21:58:02 1986
Date-Received: Fri, 28-Feb-86 05:20:45 EST
Distribution: net
Organization: AT&T Bell Laboratories, Summit, NJ
Lines: 62

There have been several thoughtful submissions on the subject
of integer division in C recently.  I think the ANSI X3J11
position should be introduced into the discussion.

This issue reveals the fundamental dichotomy in C -- between
the systems-programmers' language (replacing assembly language)
and the application-programmers' language (replacing FORTRAN or
Pascal, say).

System programmers really are not concerned about the behavior
when a negative number is involved.  Except perhaps for -1,
negative numbers are considered harmful in this arena.  The
goal of division is to get the positive quotient or positive
remainder as fast as the hardware can give it, and this will
always be hardware-independent.

Application programmers, on the other hand, ARE concerned about
portable division involving negative numbers, a need which C
does not address.  When this was discussed (at many Standards
meetings), the following positions emerged:

1.  Ignore the problem -- reliable application programs are
    not important.
2.  Force the compiler to generate code to produce portable
    semantics -- fast systems programs are not important.
3.  Enrich the language by adding semantics to the new
    ``signed'' keyword, which is at present redundant for
    int's.  This proposal would also have solved the problem
    of reliable semantics for right-shifting of negative
    int's.  It leads to 12 types of integers (``plain'',
    unsigned and signed; char, short, ``plain'' and long) and
    runs slightly afoul of the widening rules (signed char would
    widen to signed int, not ``plain'' int).  It was defeated at
    two successive meetings by a very narrow vote, and I have
    given up on it.
4.  Enrich the language by adding new operators (// and %%)
    to signify reliable signed division where desired.  (I
    tolerated this proposal until the // comment convention of
    C++ appeared.)
5.  Enrich the library by adding functions that do reliable
    signed division.  (Functions can be implemented as macros
    in ANSI C if appropriate, because their names are reserved.)
    The functions invented for this purpose are:
        typedef struct { int quot, rem; } idiv_t;
	idiv_t idiv(int numer, int denom);
    and
        typedef struct { long int quot, rem; } ldiv_t;
	ldiv_t ldiv(long int numer, long int denom);
    The semantics are those of FORTRAN:  The sign of the quotient
    and remainder are the same as the sign of the mathematical
    quotient.  The behavior on exceptions such as overflow or
    divide-by-zero is undefined, just like regular division.
    (Note that these are the only functions in the library that
    return structs.)

The functions were added last December, and could still be challenged.
Constructive comments on this "solution by committee" would be
appreciated, either on the Net or to me by e-mail.

Larry Rosler, AT&T
Editor, X3J11
ihnp4!attunix!lr, 201-522-5086