[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