Max Kirillov writes:
> If nobody objects changing the user-visible behavior, I'll
> consider using this.
What user-visible behaviour? A user tries to use a new test helper
introduced by the previous round and does not find it? That's OK.
> PS: I'll respond to your other
On Tue, Nov 28, 2017 at 10:26:33PM -0500, Jeff King wrote:
> On Mon, Nov 27, 2017 at 12:40:51AM +0200, Max Kirillov wrote:
> That said, we already have some precedent in "git version
> --build-options" to report sizes there. Can we do something like the
> patch below instead of adding a new test
On Mon, Nov 27, 2017 at 12:40:51AM +0200, Max Kirillov wrote:
> > Rather than introducing a new 'test' program, would it be possible to
> > get by with just using 'printf' from the shell?
> >
> > % printf "%zu\n" -20
> > 18446744073709551596
>
> I thought about it, of course. But, I am
Max Kirillov writes:
> Add tests for cases:
>
> * CONTENT_LENGTH is set, script's stdin has more data.
> (Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero
> and fail. It does not seem to cause any performance issues with the default
> value of
On Sun, Nov 26, 2017 at 05:18:55PM -0500, Eric Sunshine wrote:
> On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote:
>> +int cmd_main(int argc, const char **argv)
>> +{
>> + if (argc == 2 && strcmp(argv[1], "(size_t)(-20)") == 0)
>> + printf("%zu",
On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote:
> Add tests for cases:
>
> * CONTENT_LENGTH is set, script's stdin has more data.
> (Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero
> and fail. It does not seem to cause any performance issues
Add tests for cases:
* CONTENT_LENGTH is set, script's stdin has more data.
(Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero
and fail. It does not seem to cause any performance issues with the default
value of GIT_HTTP_MAX_REQUEST_BUFFER.)
* CONTENT_LENGTH is
7 matches
Mail list logo