Pickle `FLOAT` opcode inconsistency with whitespace

[Legoclones]

Bug report

Bug description:

A lot of Python code tolerates leading and trailing whitespace in string-to-number conversions. However, in the FLOAT opcode of pickle, the Python implementation can tolerate leading/trailing whitespace, while the C implementation throws an error and can't convert it. Note that the INT opcode can gracefully handle leading/trailing whitespace (in both Python and C).

Payloads:

payload:      b'F 5\n.'

pickle:       5.0
_pickle.c:    FAILURE could not convert string to float: ' 5
'
pickletools:
    0: F    FLOAT      5.0
    4: .    STOP
highest protocol among opcodes = 0

payload:      b'F5 \n.'

pickle:       5.0
_pickle.c:    FAILURE could not convert string to float
pickletools:
    0: F    FLOAT      5.0
    4: .    STOP
highest protocol among opcodes = 0

payload:      b'I 5 \n.'

pickle:       5
_pickle.c:    5
pickletools:  
    0: I    INT        5
    5: .    STOP
highest protocol among opcodes = 0

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

• gh-135580: Pickle FLOAT opcode supports whitespace #135619

[serhiy-storchaka]

There is no requirement to handle leading and trailing whitespaces. The discrepancy between Python and C implementation can be solved in two ways:

1. Treat them as errors.
2. Always ignore them.

I do not know good reasons to specially support leading and trailing whitespaces. But detecting them may have non-zero cost which will exceed the benefit. So we can leave this as is, unless you have a very simple and cheap solution.

[Legoclones]

The first option of treating them as errors would be difficult since the int() and float() Python functions tolerate whitespace by default. Therefore, switching the FLOAT opcode C implementation to tolerate whitespace would probably be the best option. I did some searching around and the PyFloat_FromString() conversion function tolerates whitespace in it.

I've attached a PR that changes the load_float() function to use PyFloat_FromString() now instead of char* -> double -> PyFloat conversion. The code also looks cleaner to me. All tests pass, and I don't see any instances where char* -> PyUnicode -> PyFloat leads to any incorrect/unexpected conversions than the char* -> double -> PyFloat conversion it was before. I haven't tested the efficiency of this specific function though so I don't know if it's quicker/slower.