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] Fix builtin strcpy


On Mon, Jun 23, 2003 at 01:54:59PM -0700, Richard Henderson wrote:
> On Mon, Jun 23, 2003 at 03:08:37PM +0200, Jakub Jelinek wrote:
> >    len = c_strlen (src);
> > -  if (len == 0)
> > +  if (len == 0 || TREE_SIDE_EFFECTS (len))
> 
> Seems like c_strlen should return NULL for this, otherwise lots
> of other places in builtins.c would need updating.

I discovered this by code inspection when thinking about the
c_strlen improvement posted in the other patch.
All other uses of c_strlen seems to be ok in this regard:
a) expand_builtin_strlen calls expand_expr on the result, ie.
   doesn't care if it has side-effects or not, they will be evaluated
   as they should
b) expand_builtin_strcpy had this bug
c) expand_builtin_stpcpy calls c_getstr first, and c_getstr is guaranteed
   to return NULL if c_strlen might ever return side-effects
d) expand_builtin_strncpy checks c_strlen for INTEGER_CST, bails otherwise
e) expand_builtin_strcmp and expand_builtin_strncmp allow side-effects
   on c_strlen from one argument only, there is code to deal with it
f) expand_builtin_fputs checks c_strlen for INTEGER_CST
g) fold_builtin returns c_strlen return value, ie. if it has side-effects
   it will be evaluated properly later when expanded

Maybe just comments above c_strlen could be improved to warn about this.

	Jakub


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