Re: Ancient history

From: Nick Maclaren (nmm1_at_cus.cam.ac.uk)
Date: 06/12/05

  • Next message: Tristan Beeline: "I think the Illuminati know all passwords !!!" 
    Date: 12 Jun 2005 07:30:09 GMT

    In article <fZCdnctIVOMw0zbfRVn-uw@comcast.com>,
    glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
    >Nick Maclaren wrote:
    >
    >> All of that is true, and I have similar experiences, but the issue
    >> here IS the abstraction. C's model of arrays and areas of data
    >> is precisely that of a pointer to the start - with no length
    >> included or includable.
    >
    >I always thought it was possible to do in C, but there doesn't seem
    >much interest in actually doing it. If a pointer holds origin, current
    >offset, and length then it is possible to do bounds checking even with
    >pointer arithmetic.

    No. As I have posted before, it ISN'T possible in C, for reasons I
    explain in my Objects diatribe. There is more than is in that
    document, too, including C99's introduction of intptr_t, but that
    gives a good start.

    The best that is possible in C is the following:

        A reference is checked that it refers to a correctly aligned
        segment of memory wholly contained within a single allocation
        (i.e. a definition, result of malloc etc.)

        A pointer value that is operated on using only the pointer
        operations defined in the standard (i.e. not intptr_t or any
        of the numerous permitted extensions) does not change a pointer
        into one allocation into a pointer into another.

    You CANNOT block overflows from one subsection of an allocation
    into another, in general, without changing the standard drastically.

    Equally badly, where languages like Fortran 77 can have reliable
    bounds checking for a small, constant overhead per reference,
    the situation in C is such that the overhead is generally log(N)
    with a larger constant, where N is the number of non-definition
    allocations (often a million plus). Ouch.

    Oh, and hardware support wouldn't help, unless it was designed entirely
    for C's bizarre rules - which changed quite radically between K&R C,
    C89 and C99. Think pointer validity and weep.

    >I was interested in the possibility of a C compiler targeting JVM,
    >which has those restrictions. There are some additional complications
    >regarding struct and union, but for a large fraction of C code it should
    >be possible.

    It depends how you define "a large fraction". In particular, it
    doesn't include any program that uses any form of the X Windowing
    System, or any program which includes a fancy memory management
    system or "dump/restore" system.

    >> It is possible to build an abstraction on top of that which includes
    >> both the pointer and its size, but that is a separate model. Many
    >> of the more robust C programs do precisely that - which is precisely
    >> using C as a semi-portable assembler, as it was designed for.
    >
    >In either case there is some overhead to actually doing it.
    >That seems to be the biggest reason not to do it.

    There is. My belief is that, in a language like Fortran, the overhead
    could be as little as 20%. The analysis used to optimise code provides
    exactly the right information needed to generate efficient checking.
    Unfortunately, there are two obstacles to adding it to existing
    compilers:

        Changes to the data structures (including argument passing) are
        needed. Not major ones, but enough to cause compatibility trouble.

        The domination of benchmarketing means that money spent on adding
        1% of performance is good, but money spent on adding reliability
        is bad.

    However, please note that NAG Fortran 95 does indeed have such checking.
    I don't know if any other Fortran 95 compilers do, but a lot of
    Fortran 77 ones did.

    Regards,
    Nick Maclaren.

  • Next message: Tristan Beeline: "I think the Illuminati know all passwords !!!"

    Relevant Pages

    • fortran pointer structure
      ... and fortran subroutine. ... argument (where it is defined as a pointer). ... direction (allocation in Fortran and write in the allocated space in C++). ... total nunber of elements (1st dimension size)* ...
      (comp.lang.fortran)
    • Re: Passing allocatable arrays between Fortran and C
      ... then passed back to the calling Fortran code. ... pass an array descriptor or dope vector, which is a structure containing a pointer ... One variant of it is to pass a pointer ") to C and do the allocation ...
      (comp.lang.fortran)
    • Re: [C++] Returning objects from a function and performance
      ... >>overhead here is probably the memory allocation. ... > a pointer to any data that exceded the machine word size. ... > I have little idea of the details on runtime pointer allocation but I ... the cleanest/simplest design doesn't give the performance you ...
      (alt.comp.lang.learn.c-cpp)
    • Re: Passing allocatable arrays between Fortran and C
      ... then passed back to the calling Fortran code. ... pointer and then allocated that C pointer; that for sure won't work, ... The only way I could think of is for the C routine to call a Fortran ... again having the C routine call a Fortran routine to do the allocation. ...
      (comp.lang.fortran)
    • Re: Matlab Vectorisation Speed - How is it done in c++?
      ... traffic is more of a problem than register allocation, ... The old canard about pointer aliasing semantics being weaker in C than ... in Fortran hasn't been an issue even in principle for almost 10 years ... matrix multiplication is simple enough that it's not *too* ...
      (comp.soft-sys.matlab)