Re: Bug in macLib

[Andrew Johnson <anj@aps.anl.gov>]

On Wednesday 31 March 2010 11:00:30 you wrote:
> Ah, I see.  So is this a better change to macExpandString?
>
> --- macCore.c.orig	2010-03-31 08:31:20.000000000 -0700
> +++ macCore.c	2010-03-31 08:58:32.000000000 -0700
> @@ -198,6 +198,10 @@
>      if ( handle->debug & 1 )
>          printf( "macExpandString( %s, maxlen = %ld )\n", src, maxlen );
>
> +    /* Check size */
> +    if (maxlen <= 1)
> +        return -1;
> +
>      /* expand raw values if necessary */
>      if ( expand( handle ) < 0 )
>          errlogPrintf( "macExpandString: failed to expand raw values\n" );
> @@ -211,7 +215,7 @@
>      s  = src;
>      d  = dest;
>      *d = '\0';
> -    trans( handle, &entry, 0, "", &s, &d, d + maxlen );
> +    trans( handle, &entry, 0, "", &s, &d, d + maxlen - 1 );
>
>      /* return +/- #chars copied depending on successful expansion */
>      length = d - dest;

Actually I think the real bugs only occur in macEnvExpand() and in the 
function check() in macLibTest.c, but given the unusual definition of the 
maxlen parameter I think it would be safest to change the parameter meaning as 
you suggest (maybe rename maxlen to buflen?) *and* modify all the places where 
it's currently used correctly.

If you generate a patch for this, please:

1. Also modify the comment describing the maxlen parameter, to clarify
2. Fix the length argument in the calls to macExpandString() in
      db_yyinput() - dbStatic/dbLexRoutines.c
      myInputFunction() - as/asLibRoutines.c
3. Attach it to a comment on the Launchpad bug report
	https://bugs.launchpad.net/epics-base/+bug/551909

Thanks,

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte