[coreboot] lar directory handling patch

Myles Watson mylesgw at gmail.com
Wed Feb 27 21:17:49 CET 2008


Here's another try.

On Mon, Feb 25, 2008 at 4:34 PM, Peter Stuge <peter at stuge.se> wrote:
> On Mon, Feb 25, 2008 at 01:47:59PM -0700, Myles Watson wrote:
>  >                               strncpy(fullname, name, MAX_PATH);
>  > +                             strncpy(fullpathname, pathname, MAX_PATH);

I took out strncpy and strncat.

>  > +                             strncat(fullpathname, namelist[n]->d_name,
>  > +                                     MAX_PATH);
>  > +
>  > +                             add_files(fullname,fullpathname,thisalgo);
>
>  This algorithm protects against overflow, but I would like if it also
>  raised an error when MAX_PATH isn't big enough.

Fixed in the same way as the last patch I submitted.  This one supersedes it.

>  > +int add_files(const char *name, const char * pathname_in,
>  > +             const enum compalgo algo_in)
>  ..
>  > +             ret = lar_process_name((char*)name, &filename, &pathname, &thisalgo);
>
>  Why is this cast needed? Does lar_process_name() modify name? If not
>  please fix it's prototype so no cast is needed.

I changed it so that the options processing gets done in lar.c with
the rest of the options processing, which lets it be a const char *.

>
>  > +     /*printf("%s: %s (%s:%s)\n",__FUNCTION__,name,filename,pathname);*/
>
>  Is there some debug functionality in lar for these?

Yes, I changed them to if (verbose()) printf ...

Myles

Signed-off-by: Myles Watson <mylesgw at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_lar_paths.diff
Type: text/x-patch
Size: 8599 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080227/ca631aa9/attachment.diff>


More information about the coreboot mailing list