[coreboot] lar directory handling patch
peter at stuge.se
Tue Feb 26 02:54:38 CET 2008
On Mon, Feb 25, 2008 at 05:00:41PM -0700, Myles Watson wrote:
> > > MAX_PATH
> Sure, I can add that. I guess I should be more careful about the
> math for the strncat too.
> Again I guess we're hoping that no one will ever use really long
> directory names and deep nesting on us.
I admit it is currently completely unlikely since coreboot doesn't
care about anything deeper than two levels anyway.
> > > +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.
> It does. It changes ':' to '\0' for files like:
Ah. Then removing const from the name parameter in add_files() would
be better, right?
> > > + /*printf("%s: %s (%s:%s)\n",__FUNCTION__,name,filename,pathname);*/
> > Is there some debug functionality in lar for these?
> Not that I saw. You're talking about a verbose switch or something
> like that?
> > > + output_elf_segments(lar, file->pathname, ptr, size,
> > > file->algo
> > How does this work with file->algo vs. zeroes compression?
> It doesn't change it. The .bss segment is treated specially, and
> overrides the compression mode.
More information about the coreboot