[xpost] a new C/C++ type that when overflow i see it

Discussion in 'C Programming' started by ¬a\\/b, Aug 9, 2007.

  1. ¬a\\/b

    jacob navia Guest

    Obviously there will be implementations of C where the machine has no
    floating point unit. In those machines, maybe this thing can
    be skipped.

    Well it is missing the specifications of WHAT HAPPENS in case of integer
    overflow.
    Floating point is optional. I have seen many implementations of C
    (and done several with the embedded versions of my compiler system)
    where there wasn't any floating point at all!

    But IF there is floating point, it must be implemented along the lines
    of the standard.

    Now, why they didn't do the same for the integer exceptions (division by
    zero, overflow) it is a mystery.

    In general C99 advanced the language in floating point with very good
    specifications, (environment, complex numbers) but left essential stuff
    like integer overflow unspecified.
     
    jacob navia, Aug 10, 2007
    #21
    1. Advertisements

  2. ¬a\\/b

    Ben Pfaff Guest

    I don't think that floating point is optional at all. Where do
    you get this notion?
     
    Ben Pfaff, Aug 10, 2007
    #22
    1. Advertisements

  3. ¬a\\/b

    CBFalconer Guest

    Such implementations, if lacking suitable libraries, do not meet
    the requirements of the standard. A 'unit' is not needed, but the
    operations are.
     
    CBFalconer, Aug 10, 2007
    #23
  4. ¬a\\/b

    jacob navia Guest

    From my work in machines without floating point!

    Alarm systems, communications programs, many things run without
    floating point, and in my compiler system for embedded targets
    floating point can be made completely optional.

    The compiler will issue an error with any floating point
    operation. This saves a lot of run time RAM, and the
    programmers are aware of the limitations of the CPU, so it is not
    a problem for anyone.
     
    jacob navia, Aug 10, 2007
    #24
  5. ¬a\\/b

    jacob navia Guest

    Many embedded systems run in 40-50K, with integer units period.

    Installing a full fledged floating point emulator would take precious
    RAM from the program.

    Maybe those systems are not "Standard".

    So what?

    That's life. Not everybody needs floating point!
     
    jacob navia, Aug 10, 2007
    #25
  6. ¬a\\/b

    Flash Gordon Guest

    jacob navia wrote, On 10/08/07 22:31:
    Any implementation can skip IEC 60599. The C standard does not say it
    can be skipped "if so and so is true" it just says it is optional. There
    are several good reasons it might not be followed.

    It explicitly states that it is undefined, so that is direct not indirect.
    Not in C it isn't.
    Well, they were not C implementations according to any version of the C
    standard or K&R1.
    Wrong. Floating point is not optional but conformance to IEC 60599 is.
    Not all processors handle it in the same way. They could have specified
    an optional standard, but they did not.
    Obviously a lot of people, specifically a number of those on the
    standards committees, did not consider it essential.
     
    Flash Gordon, Aug 10, 2007
    #26
  7. ¬a\\/b

    Flash Gordon Guest

    jacob navia wrote, On 10/08/07 23:00:
    I've worked on processors without FPUs but the C implementations still
    supported floating point since it is and always has been part of C.
    Yes, it's quite easy to do this, you just don't use any floating point
    in your code.
    Well, with floating point disabled it is not a C compiler, just a
    compiler for a language similar to C.
    Strangely enough most compilers don't use RAM for types that are not used.
    Well, it means the implementation does not conform to any version of the
    C standard or K&R.

    Personally I find not using things I don't want to use to be sufficient
    for the implementation not to waste resources on them. So I would always
    choose a compiler that provided floating point over one that did not so
    that *if* I later needed it I would have it. Floating point has been
    provided on processors without FPUs for a few decades at least.
     
    Flash Gordon, Aug 10, 2007
    #27
  8. The exceptions can be skipped on any implementation that does not have
    the flags as intended, not only on systems missing floating point. From
    the draft standard 7.6 par 5:
    Each of the macros FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW,
    FE_UNDERFLOW is defined if and only if the implementation supports
    the exception by means of the functions in 7.6.2.
    And 7.6.2:
    The following functions provide access to the exception flags.
    ... fegetexceptflag() ...
    So the best thing you can do is something like:

    #ifdef FE_OVERFLOW
    fegetexceptflag(...)
    #else
    /* other means to check for overflow */
    #endif

    So if the system does not provide an overflow indicator, FE_OVERFLOW must
    not be defined, and you have no indication whether overflow did occur or
    not.

    I do not think this has changed much in the final standard.
     
    Dik T. Winter, Aug 10, 2007
    #28
  9. On a machine with no floating point unit, a conforming C
    implementation must emulate FP in software. Floating point support is
    not optional, even for standalone implementations. An implementation
    that doesn't support floating-point is no more conforming than one
    that doesn't support structs or arrays.
    My point is that the standard *explicitly* says that the behavior is
    undefined for integer overflow. See C99 6.5p5, which I quoted above.
    It's not a major point; if the behavior were merely undefined by
    omission, it would mean exactly the same thing.
    Such implementations are non-conforming. That's not necessarily a bad
    thing; they might be quite useful. (Similarly, I've heard of
    not-quite-C implementations where int is 8 bits.)
    Yes, but some of the floating-point stuff in the standard is
    mandatory, and some of it is optional. In particular, a conforming
    implementation *must* support float, double, and long double, but it
    *needn't* support Annex F:

    An implementation that defines __STDC_IEC_559__ shall conform to
    the specifications in this annex.
    Mandating some particular behavior for signed integer overflow would
    have had a significant performance impact on many systems.

    IMHO it wouldn't have been a bad idea to specify an *optional* set of
    behavior for signed integer overflow, similar to what was done for
    floating-point. But if the committee had tried to require overflow
    checking unconditionally (banning, for example, the common wraparound
    behavior on 2's-complement systems), the standard would have had even
    greater acceptance problems that it's actually had.

    If you want to argue that the standard should mandate signed integer
    overflow checking anyway, feel free to do so in comp.std.c.
     
    Keith Thompson, Aug 10, 2007
    #29
  10. Exactly, they are non-conforming.
    So this is comp.lang.c.
    I don't think anyone here has claimed otherwise. We're merely
    stating the rather obvious fact that floating-point support
    is unconditionally required by the C standard. Non-conforming
    implementations may be quite useful, but this is comp.lang.c, not
    comp.lang.almost-but-not-quite-c.
     
    Keith Thompson, Aug 10, 2007
    #30
  11. ¬a\\/b

    Ben Pfaff Guest

    A "C" implementation without floating point is non-conforming.
    It's not optional from the viewpoint of the standard.
     
    Ben Pfaff, Aug 10, 2007
    #31
  12. But such integer only implentations are not too uncommon. On a lot of
    machines there is no real point having floating point. You can always buy my
    book and see how to implement the routines yourself, should you need real
    numbers on a little 8 bit embedded controller.
    Exactly. Whilst it is better to trap on integer overflow, unless there is
    hardware support then the software will run at least half as slowly simply
    to support this feature, because every arithmetical operation requires a
    conditional. Nowadays that is often an acceptable tradeoff, but not in
    low-level routines.
     
    Malcolm McLean, Aug 11, 2007
    #32
  13. It is possible to write a non-trivial program without floating point. It is
    not possible to write one without integers, except as an exercise.
     
    Malcolm McLean, Aug 11, 2007
    #33
  14. ¬a\\/b

    ¬a\\/b Guest

    i make errors and this would be another one.
    for example i'm making a mistake if the problem not exist,
    if in real executables this problem (size_t overflow) not is found
    or if it seen in a too few number of cases
     
    ¬a\\/b, Aug 11, 2007
    #34
  15. ¬a\\/b

    Flash Gordon Guest

    Malcolm McLean wrote, On 11/08/07 06:35:
    So? The language standard, and before that K&R, still specify floating
    point as being part of the language, not an optional extra.
     
    Flash Gordon, Aug 11, 2007
    #35
  16. ¬a\\/b

    Army1987 Guest

    IIRC, on Commodore 64 Basic variables were floating-point unless
    their name ended with '%' (for integers) or '$' (for strings), and
    most programs didn't bother to use integer variables just because
    they didn't need to store fractional numbers in them.
     
    Army1987, Aug 11, 2007
    #36
  17. ¬a\\/b

    pete Guest

    I have done one too.

    It isn't.
    You can write a correct C program that doesn't use floating point.
    You can use a nonconforming C implementation
    to translate and execute it.

    q14.3 of the clc FAQ acknowledges that some implementations
    of C, only link the math library as an option, not by default.
     
    pete, Aug 11, 2007
    #37
  18. And my own language, MiniBasic has only two basic data types, strings and
    numbers. A number can be used as an array index. But most numbers will in
    fact be integers.
    However C programs is implied on comp.lang.c
     
    Malcolm McLean, Aug 11, 2007
    #38
  19. Stating the obvious is the stock in trade of the regs here.
    Next up: Water is wet.
    The problem is that y'all are acting as if Jacob has committed a crime
    by including an option in his compiler system that, when specified (and
    only then!), turns off FP in the generated code. Or, in your stilted
    terminology, compiles a C-like language.

    Get a life, guys. He ain't breaking any laws.
     
    Kenny McCormack, Aug 11, 2007
    #39
  20. ¬a\\/b

    Flash Gordon Guest

    pete wrote, On 11/08/07 12:39:
    Yes, and without that option specified they are not conforming. It is
    normal to have to specify options to make an implementation conform.

    Personally, if I was writing a compiler for a processor without and FPU
    I would implement floating point in SW, which is what the compilers for
    the TMS320C1x/2x/5x do. If this is done properly, possibly with an
    "optimising" linker that only includes code that is actually called,
    then there is no overhead for programs not using floating point and it
    is available if you actually require it.

    There is a very long history of implementing floating point in SW since
    until the 80486DX the 80x86 series of processors did not have a build in
    FPU (although one was available as a co-processor it was not fitten in
    all PCs) and it was only with the Pentium that Intel stopped doing
    versions without an FPU (the 80486SX did not have an FPU built in).
     
    Flash Gordon, Aug 11, 2007
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.