Martin said:

> Josh: it's not as simple as just changing the type code and variable type. Systems used to require all kinds of types in the length parameter of read(2) and fread(3), including int, long, and size_t. If it was int, passing size_t would lead to silent truncation. So at a minimum, a careful review of the further processing, and a test case is necessary.

file_read() calls Py_UniversalNewlineFread() to do the actual reading.  The length argument of Py_UniversalNewlineFread(), "n", is already of type size_t, and it passes this parameter in to fread() for the number-of-elements argument.  Py_UniversalNewlineFread() is also used by file_readinto(), and that function already passes in a size_t.  So it's already successfully being used in 2.7.

If Python 2.7 still supports systems where fread()'s number-of-elements argument is smaller than size_t, this should already be causing a compilation warning on such platforms.  One would hope people supporting such platforms would fix it.  I don't know of any such platforms, so I cannot address this hypothetical issue.  Do you know of platforms supported by 2.7 where fread's number-of-elements parameter is smaller than size_t?


Antoine said:

> The benefit of fixing this in the next 2.7.x iteration is small compared to the cost of a potential regression in the core I/O implementation.

Although nobody wants to cause a regression in CPython, I'm having difficulty imagining how this change could plausibly cause one.  On the other hand, Matt makes it clear that it's a bug that has bitten hg, so I think it's worth fixing.

Can you suggest a way this change could plausibly cause a regression?