I have a function something like this:

char *foo(...)
        char *result;
        switch (...) {
        case 1:
             result = strdup(...);
        case 2:
             result = strdup(...);
        case 3:
             result = malloc(...);
             strcpy(result, "a");
             for (...) {
                strcat(result, ...);
        return result;

So there are a number of branches, most of which are pretty easy for
splint to check, but there's one hard one (involving traversing a
linked list) which it's not likely to be able to check.  So I get the

        Returned storage result not completely defined
                       (*result is undefined): (result)
  Storage derivable from a parameter, return value or global is not defined.
  Use /*@out@*/ to denote passed or returned storage which need not be defined.
  (Use -compdef to inhibit warning)

So how do I say, within this one branch, that result really has been
defined?  I know I could switch off compdef checking for the whole
function, but that seems undesirable in general (although probably OK
for this case, since the part that splint probably can't check is the
non-trivial part of the function).

I think I have a similar situation (similar because I think I want to
make a declaration about a variable in one branch) where a function is
mostly returning structure elements, but on one branch it returns the
static string "".  It does this kind of thing:

      case MDT_ATTR:
        ns_uri = node_data->d.attr->ename->ns_uri;

    if (ns_uri == NULL)
        ns_uri = "";
    return (ns_uri);

This produces the warning:

 mdoctree.c:669:2: Clauses exit with ns_uri referencing unqualified static
                     storage in true branch, local storage in continuation
  The state of a variable is different depending on which branch is taken. This
  means no annotation can sensibly be applied to the storage. (Use -branchstate
  to inhibit warning)
   mdoctree.c:669:2: Storage ns_uri becomes unqualified static

So how do I fix this?  It feels like /*@observer@*/ is almost the
right thing: if the function were only returning mysterious pointers
which the callers shouldn't fiddle with, then declaring the result as
/*@observer@*/ ought to work.  But in thise case, the warning seems
before that, so something else is required.

Bruce Stephens                  [EMAIL PROTECTED]
ACI Worldwide/MessagingDirect   <URL:http://www.MessagingDirect.com/>

Reply via email to