[coreboot] lar directory handling patch
Myles Watson
mylesgw at gmail.com
Wed Feb 27 21:32:25 CET 2008
On Wed, Feb 27, 2008 at 1:17 PM, Myles Watson <mylesgw at gmail.com> wrote:
> 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 ...
>
I realized that I was adding an extra message on a failure and
returning a value instead of exiting in lar.c main. Here's the
updated patch.
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: 8499 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080227/fb8ec6b5/attachment.diff>
More information about the coreboot
mailing list