Guillaume Pages <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
