[pacman-dev] [PATCH] Improve changelog handling

Dan McGee dpmcgee at gmail.com
Sat Dec 8 22:48:36 EST 2007


On Dec 8, 2007 7:55 PM, Allan McRae <mcrae_allan at hotmail.com> wrote:
> Xavier wrote:
> > On Fri, Dec 07, 2007 at 05:56:32PM -0600, Aaron Griffin wrote:
> >
> >> True, we don't need to. The current function is returning a
> >> alpm_list_t that contains lines, but i guess it's not really needed.
> >> We can return the full text as one big string, and leave it up to
> >> front ends to do some sort of parsing if they wish
> >>
> >>
> >
> > Something like this ? :
> >
> >
> I like the idea of not creating a temporary file.
>
> <snip>
> > +
> > +     while(!done) {
> > +             changelog = realloc(changelog, size + bufsize);
> > +             p = changelog + size;
> > +             size += bufsize;
> > +             if(pkg->origin == PKG_FROM_CACHE) {
> > +                     n = fread(p, 1, bufsize, fp);
> > +             } else if(pkg->origin == PKG_FROM_FILE) {
> > +                     n = archive_read_data(archive, p, bufsize);
> > +             }
> > +             if(n != bufsize) {
> > +                     done = 1;
> > +                     *(p+n) = '\0';
> > +             }
> > +     }
> > +
> <snip>
>
> I'm concerned all the realloc statements may get expensive if the
> changelog is too long.  How about sticking to the alpm_list_t return
> type and just dumping each buffer read into the list?  This would
> require changing the dump_pkg_changelog to not put a newline after the
> ouput of every list item if PKG_FROM_FILE.  Would that be any better?
>
> Allan

This was exactly what i was thinking- get chunks at a time from the
backend. I was thinking that the front end would allocate a buffer
(this is similar to how other libs and even things like a glibc read
work) and pass the buffer and size to the backend, and then the
backend would fill it.

I'll see what I can hack together- nothing like having 18 different
people working on the same patch. :)

-Dan




More information about the pacman-dev mailing list