git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

From
Randall S. Becker <rsbecker@nexbridge.com>
Date
Feb 8, 2015, 02:32 UTC
Message-ID
<020e01d04347$7efbe200$7cf3a600$@nexbridge.com>
In-Reply-To
<CAPc5daXD_7XZD5Vag51BjrSZ0q1r9eMswhLmnpUFqqjrc9oSTw@mail.gmail.com>
On Feb 7 2015 at 9:14 PM Junio C Hamano wrote:
Show 28 quoted lines
>On Sat, Feb 7, 2015 at 2:31 PM, Joachim Schmitz <jojo@schmitz-digital.de> wrote:
>> Junio C Hamano <gitster <at> pobox.com> writes:
>>>
>>> Yup, I agree that is a sensible way to go.
>>>
>>>  (1) if Makefile overrides the size, use it; otherwise
>>>  (2) if SSIZE_MAX is defined, and it is smaller than our internal 
>>> default, use it; otherwise
>>>  (3) use our internal default.
>>>
>>> And leave our internal default to 8MB.
>>>
>>> That way, nobody needs to do anything differently from his current 
>>> build
>> set-up,
>>> and I suspect that it would make step (1) optional.
>>
>> something like this:
>>
>> /* allow overwriting from e.g. Makefile */ #if !defined(MAX_IO_SIZE) # 
>> define MAX_IO_SIZE (8*1024*1024) #endif
>> /* for plattforms that have SSIZE and have it smaller */ #if 
>> defined(SSIZE_MAX && (SSIZE_MAX < MAX_IO_SIZE) # undef MAX_IO_SIZE /* 
>> avoid warning */ # define MAX_IO_SIZE SSIZE_MAX #endif
>No, not like that. If you do (1), that is only so that the Makefile can override a broken definition a platform may give to SSIZE_MAX.  So
> (1) if Makefile gives one, use it without second-guessing with SSIZE_MAX.
> (2) if SSIZE_MAX is defined, and if it is smaller than our internal default, use it.
> (3) all other cases, us our internal default.
That is reasonable. I am more concerned about our git-upload-pak (separate thread) anyway :)
Cheers, Randall
Previous: Junio C HamanoNext: Joachim Schmitz
Message 10 of 20 in “read() MAX_IO_SIZE bytes, more than SSIZE_MAX?”
  1. Joachim SchmitzFeb 7, 2015
  2. Joachim SchmitzFeb 7, 2015
  3. Torsten BögershausenFeb 7, 2015
  4. Joachim SchmitzFeb 7, 2015
  5. Joachim SchmitzFeb 7, 2015
  6. Torsten BögershausenFeb 7, 2015
  7. Junio C HamanoFeb 7, 2015
  8. Joachim SchmitzFeb 7, 2015
  9. Junio C HamanoFeb 8, 2015
  10. Randall S. BeckerFeb 8, 2015
  11. Joachim SchmitzFeb 8, 2015
  12. Eric SunshineFeb 8, 2015
  13. Junio C HamanoFeb 11, 2015
  14. Joachim SchmitzFeb 11, 2015
  15. Joachim SchmitzFeb 11, 2015
  16. Junio C HamanoFeb 11, 2015
  17. Randall S. BeckerFeb 7, 2015
  18. Randall S. BeckerFeb 7, 2015
  19. Joachim SchmitzFeb 7, 2015
  20. Joachim SchmitzFeb 7, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.