This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] __attribute__((nonnull))


On Sun, 19 May 2002, Jason R Thorpe wrote:

> Hm.  Okay.  Should the nonnull code be moved into c-format.c, then?  Or
> should c-format.c export the recursion mechanism?
> 
> I was hoping to keep the null check stuff completely separate from the
> format check stuff -- it just seemed more clean to do so.  (I mean,
> decoupling them is really the whole point...)

Logically, they both follow the theme of checking properties of the
arguments of a function that are beyond those required by prototype
checking.  Checking for null-termination of lists of arguments of certain 
functions, also suggested in this connection, fits the same theme.  (For 
that reason, I think nonnull checking, as with straight format checking, 
should be controlled by -Wformat.  But a separate option, enabled by 
-Wall, would be reasonable as well.)

The recursion mechanism ought to be exported - either in c-format.c, or 
separately in c-common.c.  (Note that the later parts of 
check_format_info_recurse, which handle such things as "string"+constant, 
outside the recursion, are specific to format checking, and would need to 
be separate from the recursion mechanism.)

Since the existing format checking will recurse down into gettext/ngettext
calls, for nonnull attributes to replace the null pointer checking in
format checking, that recursion should in any case be implemented for the
null pointer checking.

> Ok, I have updated the documentation to say that the compiler issues
> a warning when it encounters a null being passed in an argument marked
> as non-null.
> 
> (I certainly think using this information for optimization purposes is
> a fine thing to do, but I have not implemented that, obviously...)

If it might be used for optimisation in future, the docs need to say so.  
Otherwise someone might start using it for functions where explicit NULL
is a bad idea, but it is valid for an argument to be a null pointer, then
get unexpected code generation changes when the specification of the
attribute changes under them.

> Test cases added.  Updated patch attached.

You need to test the various errors for invalid uses of the __attribute__.  
(Every diagnostic should have at least one test.  Tests specifically for 
__attribute__ for format attributes are in gcc.dg/format/attr-[1-7].c.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk


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