“restrict” keyword in header files

It would appear that Mac OS X’s copy of string.h is invalid.

It declares strcpy as

char *strcpy(char *, const char *);

But the C standard declares it as

char *strcpy(char * restrict, const char * restrict);

These two types are actually incompatible with each other according to the C standard, and a function that is declared  more than once in different translation units with different declarations is considered undefined behavior. Thus, any correctly conforming C library will cause any code that includes string.h to be undefined.

Oops!

6 thoughts on ““restrict” keyword in header files

  1. Interesting find, but… how meaningful is it really? As you say, “any correctly conforming C library will cause any code that includes string.h to be undefined”. But if the C library included with OS X is coherent with the .h file (and thus not strictly conforming to the standard), then no Undefined Behavior should appear.

  2. The consequence is that if I write code on OSX that assumes that the C library is not restrict-qualifying these types, that code may not port to other platforms, and may lead to extremely subtle bugs that are not visible at the source level because the arise from the way in which the C compiler is optimizing aliasing restrictions.

Leave a Reply

Your email address will not be published. Required fields are marked *