git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Ben Peart <Ben.Peart@microsoft.com>,
	Ben Peart <peartben@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Cc: "christian.couder@gmail.com" <christian.couder@gmail.com>,
	"larsxschneider@gmail.com" <larsxschneider@gmail.com>
Subject: Re: [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently()
Date: Thu, 30 Mar 2017 16:04:09 +0200	[thread overview]
Message-ID: <a5e259bd-d994-6ddb-9dae-43531ee2e875@web.de> (raw)
In-Reply-To: <BL2PR03MB3233616BE57BB7D911B1AAEF4330@BL2PR03MB323.namprd03.prod.outlook.com>


[snip]
>> Would packet_write_lines make more sense ?
>>
>
> Just goes to prove that there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. :)  The feedback on V1 was:
>
> "I am hesitant to take a function that does not take any "list"
> type argument and yet calls itself "write_list".  IOW, I'd expect something like these
>
> 	write_list(int fd, const char **lines);
> 	write_list(int fd, struct string_list *lines);
>
> given that name, and not "varargs, each of which is a line".  I am tempted to suggest
>
> 	packet_writel(int fd, const char *line, ...);"
>
>>> +{
>>> +	va_list args;
>>> +	int err;
>>> +	va_start(args, line);
>>> +	for (;;) {
>>> +		if (!line)
>>> +			break;
>>> +		if (strlen(line) > LARGE_PACKET_DATA_MAX)
>>> +			return -1;
>>> +		err = packet_write_fmt_gently(fd, "%s\n", line);
>>> +		if (err)
>>> +			return err;
>>> +		line = va_arg(args, const char*);
>>> +	}
>>> +	va_end(args);
>>> +	return packet_flush_gently(fd);
>>> +}
>>> +
>> I don't think that this va_start() is needed, even if it works.
>>
>> int packet_write_line(int fd, const char *lines[])
>> |
>> 	const char *line = *lines;
>> 	int err;
>> 	while (line) {
>> 		if (strlen(line) > LARGE_PACKET_DATA_MAX)
>> 			return -1;
>> 		err = packet_write_fmt_gently(fd, "%s\n", line);
>> 		if (err)
>> 			return err;
>> 		lines++;
>> 		line = *lines;
>> 	}
>> 	return packet_flush_gently(fd);
>> ]
>>
>
> This is a helper function to simply the common pattern of writing out a variable number of lines followed by a flush.  The usage of the function as currently implemented is:
>
> packet_writel(fd, "line one", "line two", "line n");


Does this work ?
I would have expected
packet_writel(fd, "line one", "line two", "line n"), NULL;

>
> which requires the use of variable number of arguments.  With your proposal that convenience is lost as you have to create an array of strings and pass that instead.  The usage just isn't as simple as the current model.
>
What is wrong with

int packet_write_fmt_gently(int fd, const char *fmt, ...)
and we use it like this:
if packet_write_fmt_gently(fd, "%s%s%s", "line one", "line two", "line n")



(Or do we need another one like)
int packet_write_fmt_gently_flush(int fd, const char *fmt, ...)

Sorry if I am lost here

  reply	other threads:[~2017-03-30 14:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 15:27 [PATCH v2 0/2] Refactor the filter process code into a reusable module Ben Peart
2017-03-24 15:27 ` [PATCH v2 1/2] pkt-line: add packet_writel() and packet_read_line_gently() Ben Peart
2017-03-25  5:47   ` Torsten Bögershausen
2017-03-27 22:19     ` Ben Peart
2017-03-30 14:04       ` Torsten Bögershausen [this message]
2017-03-30 16:01         ` Ben Peart
2017-03-30 17:01           ` Torsten Bögershausen
2017-03-24 15:27 ` [PATCH v2 1/4] t7800: remove whitespace before redirect Ben Peart
2017-03-24 16:21   ` Ben Peart
2017-03-24 15:27 ` [PATCH v2 2/2] sub-process: refactor the filter process code into a reusable module Ben Peart
2017-03-27 18:59   ` Jonathan Tan
2017-03-27 23:54     ` Ben Peart
2017-03-24 15:27 ` [PATCH v2 2/4] t7800: cleanup cruft left behind by tests Ben Peart
2017-03-24 15:27 ` [PATCH v2 3/4] difftool: handle modified symlinks in dir-diff mode Ben Peart
2017-03-24 15:27 ` [PATCH v2 4/4] Git 2.12.1 Ben Peart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a5e259bd-d994-6ddb-9dae-43531ee2e875@web.de \
    --to=tboegi@web.de \
    --cc=Ben.Peart@microsoft.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=peartben@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).