Roland Mainz writes:
> > int
> > foo(int *x)
> > {
> > return (0);
> > }
[...]
> Note that this fails if function |foo()| is in a different library and
> cannot be processed by "lint" (Sun Studio's "cc" has "-xipo" which may
> be able to help a bit... but "lint" doesn't have a similar option... ;-(
> ) ...
I'd prefer to have something like this available:
NOTE(ALWAYSWRITES(x));
The notation (for lint) would mean "x is a pointer and this function
always writes a value into the location pointed to by it before
returning, and doesn't rely on the value that was in that location on
entry."
The idea is that I would be able to kill at least three birds with one
stone. In the called function (the definition), lint could warn me if
I ever return without writing through the pointer as advertised. In
the calling function, lint would know that the pointed-to value isn't
uninitialized. Finally, future maintainers would know what semantics
I _intended_ to have for the function, because they'd see this
notation in the source.
Similar arguments could be made for:
NOTE(READSFROM(x));
NOTE(READSTHENWRITES(x));
Obviously, those examples are just simple scalars. Even if that's all
the system could support tracking, I think it'd be useful. For
composite types, you _might_ need finer-grained attributes.
More generally, I wish we had more ways to signal intent. The more
that are present, the more I can write code that's easier to maintain
and that can be statically checked for flaws. Since it ends up saving
me time, I'd use those features if I had 'em.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
