Guillaume Pages <guillaume.pa...@ensimag.grenoble-inp.fr> writes:

> I felt that was not the right way to do so. What do you think of a
> function like that:
>
> /*
>  * Puts nb_commands commands from filename in lines,
>  * returns the total number of commands in the file
>  * ignores comments and empty lines
>  * lines needs to be at least of size nb_commands
>  * part: 0 get last commands
>  *     1 get first commands
>  */
>
> int get_commands(char *filename, int nb_commands, char **lines, int part)
>
> Maybe part is not the best word to choose to take the beginning or the end
> of the file. I also hesitate about adding a parameter to ignore or not the 
> comments.

If I were doing the caller of these two functions, then instead of
adding these specialized helpers, I'd probably structure that caller
this way:

        struct strbuf buf = STRBUF_INIT;
        struct string_list have_done = STRING_LIST_INIT_DUP;
        struct string_list yet_to_do = STRING_LIST_INIT_DUP;
        int have_done_nr, yet_to_do_nr;

        strbuf_read_file(&buf, ".../done", 0);
        stripspace(&buf, 1);
        have_done_nr = string_list_split(&have_done, buf.buf, '\n', -1);
        strbuf_release(&buf);

        strbuf_read_file(&buf, ".../todo", 0);
        stripspace(&buf, 1);
        yet_to_do_nr = string_list_split(&yet_to_do, buf.buf, '\n', -1);
        strbuf_release(&buf);

Then have_done.items[have_done_nr - 1].string would be the last one
that we have replayed, and yet_to_do.items[0].string would be the
next one we are going to replay.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to