logancapaldo's comments

logancapaldo · on Dec 8, 2013

What if it's not a DWIM compiler? I'm pretty sure (happy to be corrected) pointer <-> integer conversions are implementation defined. Therefore casting between could perform some reversible operation that ensured round tripping worked, but does not require that ptr(a - b) == a - b even though a == int(ptr(a)) holds.

cperciva · on Dec 9, 2013

I'm pretty sure (happy to be corrected) pointer <-> integer conversions are implementation defined.

Quite correct, subject to the requirement that converting the same uintptr_t value back to (void ) will return the original pointer. So the conversion could be implemented as a hash table if the compiler author wanted.

But if you look carefully at what I wrote, I'm never converting a value which was not previously returned by a (void )->(uintptr_t) conversion.

logancapaldo · on Dec 9, 2013

I see. What I was worried about was a version of the code you didn't actually write (casting the ptrdiff_t result to a [u]intptr_t, not casting the pointers first).

logancapaldo · on March 25, 2012

That is not a "similar" implementation, and it's not in the "library". It exposes the OS/ABI level exception functionality (which C++ exceptions are also built atop of) to the compiler.

logancapaldo · on March 18, 2012

This article is pretty terrifying:

      #import <pthread.h>
      #import <stdlib.h>
      
      // Globals
      pthread_mutex_t *gLck;
      int gSum;

      int main (int argc, const char * argv[])
      {
          pthread_t *tFoo, *tBar;
          int tErr, tArgF, tArgB;
      
          // create the mutex construct
          tErr = pthread_mutex_init(gLck);

logancapaldo · on Oct 3, 2011

And this is why, any cache without an eviction policy and/or size limitation is bad (and memoization _is_ a cache). I shudder every time I see a "magical" memoization function whose interface is just

   memo function-to-memoize