* Basile STARYNKEVITCH <[EMAIL PROTECTED]> [070102 22:49]: > Maybe, instead of using built-ins, we could extend the __attribute__ > facility for functions (and expect the libc developers to progressively use > them). Eg > > void free(void*) __attribute((pointer_invalid(1))); > > would mean that argument #1 of function free is pointer which is invalidated > by the function. Or maybe a pragma for that.... > > Of course, the challenge is then how to have lots of attributes, and not > slow down the compiler... I don't know yet if adding hundreds on definitions > inside gcc/builtin-attrs.def would slow down the compiler. > > IMHO, adding new attributes would permit future library developers to > annotate their header files appropriately. This would be more powerful than > understanding only a given standard symbol like free. Of course, the cost of > attributes is that to use them effectively we depend upon library developers > using them actually in their headers.
splint supports this and calls those arguments "only". It has one pitfall, though, which is the realloc function. Realloc can invalidate a pointer or not, and one only knows so when looking at the return value, but I fear this is more than can be dome with simple means. I'm a big fan of such tests on compile time (there are special tools checking, but the more the compiler also does, the better). So if anyone wants to implement something like that (or for example extending checking the non-null attribute to more than rejecting NULL-constants but also variables that are always NULL) and you need testers let me know. Hochachtungsvoll, Bernhard R. Link