This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: identifing free() in tree-ssa

* Basile STARYNKEVITCH <> [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.

	Bernhard R. Link

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]