Decrement a given pointer.

Discussion in 'C Programming' started by Michael Press, Jul 9, 2013.

  1. Michael Press

    Ken Brody Guest

    It doesn't matter. Simply loading an invalid address (which is likely to
    happen when it calculates the value of "p-1") into the register can cause a
    fault.
     
    Ken Brody, Jul 10, 2013
    #41
    1. Advertisements

  2. Well it can, but for systems where that is true, and where the
    computation can (or must) be done in other registers, it is usual
    to do it such that it won't cause a fault.

    Some time ago I was considering the problem of a C compiler
    generating JVM code. The JVM 'reference' is opaque. There is no
    operation that will increment or decrement such an object.
    The offset is supplied at dereference time.

    JVM code to represent a C pointer would have an origin
    (reference object) and offset.

    Note also the C restriction on comparing pointers to different
    objects. In large model x86, the compiler only compares the offset.
    If you use a relational operator on different object, the result
    may be surprising.

    Even if the implementation does fault on generating an invalid
    address, all the C compiler has to do is be sure not to generate
    such an address until it is actually time to dereference it.
    That is, keep the origin and offset separate. There is a good
    chance that the system will require that, anyway.

    -- glen
     
    glen herrmannsfeldt, Jul 11, 2013
    #42
    1. Advertisements

  3. Michael Press

    Joe Pfeiffer Guest

    Beyond "source of much student confusion"?
     
    Joe Pfeiffer, Jul 11, 2013
    #43
  4. (snip, someone wrote)
    (then I wrote)
    I think about then I started using the Watcom compilers.
    (Both 16 bit and 32 bit compilers.)
    Well, yes, but even so every segment selector load requires
    the processor to load the 8 byte segment descriptor.
    (As far as I know, none of the processors would notice that the
    selector was the same and not reload. Even more, they could have
    put in a cache of recent segment selectors to avoid the cost
    of reloading them.)
    Well, for one on the 286 and 386 there was only ES to use.
    (At least it was usual to keep DS mostly constant throughout
    a function.) Later FS and GS were added, but late enough that
    they didn't get used much.

    Besides that, there weren't many registers. You might keep
    something in DX for a little while, but not for long.

    -- glen
     
    glen herrmannsfeldt, Jul 11, 2013
    #44
  5. Michael Press

    Nobody Guest

    If you subtract one from all indices, you get:

    The top of the heap is heap[1-1] == heap[0]
    The two subsidiary nodes to heap[k-1] are
    heap[2*k-1] == heap[2*(k-1)+1] and
    heap[2*k+1-1] == heap[2*k] == heap[2*(k-1)+2]

    Substituting k-1 == u gives:

    The top of the heap is heap[0]
    The two subsidiary nodes to heap are
    heap[2 * u + 1] and heap[2 * u + 2]
     
    Nobody, Jul 11, 2013
    #45
  6. Michael Press

    James Kuyper Guest

    In many previous discussions of C implementations with CHAR_BIT==9, I
    and others have asked for examples of such implementations, and all we
    got was silence. However, as soon as I say there are none, several
    examples are given. That says something a bit annoying about human
    psychology.
     
    James Kuyper, Jul 11, 2013
    #46
  7. Michael Press

    Les Cargill Guest


    Memory seems to work like peripheral vision - trying to remember
    in a focused fashion seems less effective than thinking
    about something else. It's as if your brain dispatches an
    archivist to go find it, and that takes a little
    while.
     
    Les Cargill, Jul 11, 2013
    #47
  8. I meant that having dedicated address registers meant it could have done
    so, not that any given implementation actually did so.

    S
     
    Stephen Sprunk, Jul 11, 2013
    #48
  9. Michael Press

    Eric Sosman Guest

    If this degree of optimizer "reasoning" seems far-fetched,
    it's not. See

    <http://www.theregister.co.uk/2009/07/17/linux_kernel_exploit/>

    .... for an example that matches none of Christian's, but is quite
    similar in spirit:

    - A pointer was dereferenced, and later checked for NULLness.

    - If the pointer were NULL, the dereference would invoke
    undefined behavior.

    - If the behavior was undefined, then it didn't matter how
    the subsequent NULLness test came out: Any result (even *no*
    result) would be permitted.

    - The NULLness test was therefore superfluous.

    - ... so the optimizer removed it.

    And, of course:

    - Linux developers blamed gcc for their own misteak.
     
    Eric Sosman, Jul 12, 2013
    #49


  10. Thanks. I will look into it.
     
    Michael Press, Jul 15, 2013
    #50
    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.