Re: [PATCH v2 3/4] pack-objects.c: do stdin parsing via revision.c's API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Change the fgets(..., stdin) parsing in pack-objects.c to use a
> now-extended version of the rev_info stdin parsing API.

This leads me to think that the stdin parsing API is already present,
but it turns out that it still needs to be extended. Maybe rewrite this
as "extend the rev_info stdin parsing API to support <whatever we need
to support>, and change the <...> in pack-objects.c to use it".

> @@ -136,6 +149,28 @@ struct rev_info {
>  	 */
>  	int consumed_stdin_per_option;
>  
> +	/*
> +	 * When reading from stdin (see "stdin_handling" above) define
> +	 * a handle_stdin_line function to consume the lines.
> +	 *
> +	 * - Return REV_INFO_STDIN_LINE_PROCESS to continue
> +	 *   revision.c's normal processing of the line (after
> +	 *   possibly munging the provided strbuf).
> +	 *
> +	 * - Return REV_INFO_STDIN_LINE_BREAK to process no further
> +	 *   lines, or anything further from the current line (just
> +	 *   like REV_INFO_STDIN_LINE_CONTINUE).
> +	 *
> +	 * - Return REV_INFO_STDIN_LINE_CONTINUE to indicate that the
> +	 *   line is fully processed, moving onto the next line (if
> +	 *   any)
> +	 *
> +	 * Use the "stdin_line_priv" to optionally pass your own data
> +	 * around.
> +	 */
> +	rev_info_stdin_line_func handle_stdin_line;
> +	void *stdin_line_priv;

I assume that all 3 of these are needed now to minimize the diff (which
is fine), but maybe comment on which of these are intended to stay and
which are only temporary. In particular, (once things are stabilized)
when would a caller need BREAK?

Also mention what happens if handle_stdin_line is not given (I presume
that it would just be like a no-op function that returns PROCESS every
time).

Looking at the bigger picture, though, and looking at the next patch,
this looks like a confusing API especially with the presence of "--not".
(In the next patch, you had to introduce a flags field, and the callback
has to remember to always handle "--not" and to toggle the flag.)
Perhaps the "--not" problem can be solved by making it revision.c's
concern and having the callback take a boolean parameter indicating
whether "--not" is active or not.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux