[PATCH] Remove clobber_region() etc

Andrew Bartlett abartlet at samba.org
Tue Mar 22 02:32:32 MDT 2011

On Tue, 2011-03-22 at 08:27 +0100, Volker Lendecke wrote:
> On Tue, Mar 22, 2011 at 06:16:03PM +1100, Andrew Bartlett wrote:
> > Certainly,
> > 
> > The outcome of the incredible macros in safe_string.h is that if you
> > have:
> > 
> > char cmdstring[200];
> > safe_strcpy(cmdstring, panic_action, sizeof(cmdstring));
> > 
> > This will fail to compile, until changed to:
> > 
> > char cmdstring[200];
> > safe_strcpy(cmdstring, panic_action, sizeof(cmdstring) -1);
> > 
> > The macro uses some really, really scary code - testing at configure
> > time that a function call will be optimised out and using the ? operator
> > to test an expression using sizeof() the first argument.  
> > 
> > Why exactly it wants it to be sizeof(x)-1 I'm not sure, but that showed
> > that the macro still works. 
> That's scary indeed. And Coverity does not like it. I think
> strlcpy is a much better API which is a lot less
> error-prone. I see the point to check if the target is the
> right size, but strcpy from my point of view could just go
> away.

Why does Coverity not like it?  The weird macro stuff can be avoided as
long as their compile doesn't define

> Just brainstorming: Is it possible to have a macro around
> strlcpy that finds the target size automatically and is only
> usable for static or stack-allocated arrays?

I certainly think I could add a checked_strlcpy().  We could use it
alongside strlcpy(), with the developer choosing to use the checked or
unchecked variant, rather than the compiler guessing. 

The big advantage of this is that the semantics would be well defined,
being only checks in addition to strlcpy(), and we would not abuse the
'safe' prefix that we keep adding to functions that can still be quite
unsafely used.

(a grep of the tree for safe_strcpy() shows a scary number of calls to
strlen() and similar things - these may all be perfectly OK, but
illustrates that calling a macro or function 'safe' doesn't make the
unsafe safe). 

Andrew Bartlett

Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

More information about the samba-technical mailing list