[LLVMdev] C as used/implemented in practice: analysis of responses

[David Chisnall]

On 7 Jul 2015, at 18:26, Chris Lattner <clattner at apple.com> wrote:
> 
> a C programmer needs to magically know that memcpy is the safe way to do this.

And, of course, has to know that if you’re implementing memcpy (or memmove, or malloc, or free) that you have to do it in a language that’s not C.  free is my favourite example here: it is UB to dereference a pointer after a call to free, so a compiler for pure standard C is completely free to optimise away the body of any function called free that stores metadata inside the object.

> However, as I’ve continued to dig into this, my feeling is that there really is no satisfactory solution to these issues.  The problem here are pervasive structural problems in the C language: In the first example above, it is that “int” is the default type people generally reach for, not “long”, and that array indexing is expressed with integers instead of iterators.  

That’s because in C89 int was defined as the natural type for the target machine.  On Alpha, int was 64 bits, but it turned out that a lot of people who wrote int really meant int32_t.  What they probably really want is int_fast32_t (the type that is at least as big as int32_t, but is the fastest thing for the target), but I’ve never seen real-world code use any of the int_fast types.  At least people are starting to use intptr_t instead of long (partly due to win64, where sizeof(long) < sizeof(void*)), though that’s been a struggle.

David