[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Function attributes

From: Nicolás Lichtmaier <nick_at_reloco.com.ar>
Date: 2006-07-11 02:57:59 CEST

I think Subversion code can benefit from the use of some function
attributes. These are some that seem to be appropiate:

malloc:
    This one marks the function as returning a newly allocated memory
area (which ensures that no already existing pointer aliases this new
pointer). I think it could be aplied to every function returning
svn_error_t*.

warn_unused_result:
    This one instruct gcc to give a warning if the returned value is
discared. This too can be used with functions returning svn_error_t*, as
it's a memory leak not to handle its return value.

format_arg:
    This function attribute declares the function as receiving a mallloc
style string. This is used in conjuction with gettext, so that xgettext
can properly mark the strings as being printf format strings. Currently
subversion lists all these functions when invoking xgettext, this is awful.

sentinel:
    Ensures that the last parameter in a variadic function is NULL.
There are many functions that expect this. This catches a silly but
common error.

APR defines __atribute__(x) to nothingif not in GCC, but many of these
attributes are only implemented in recent gcc versions, as such this
support is not sufficient. The proper way of doing this is by using
defines like SVN_GCC_WARN_UNUSED_RESULT or SVN_GCC_SENTINEL, which would
know what to do and when. This don't need to be done for attributes that
has been implemented in GCC for ever, like "printf" or (I think) "malloc".

What do you think? Is there value in this? If not I could find another
hobbie =).

Bye!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 11 02:58:54 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.