[Python-Dev] test_gzip/test_tarfile failure om AMD64

[Tim Peters]

[Thomas Wouters]
> ...
> Perhaps more people could chime in? Am I being too anal about backward
> compatibility here?

Yes and no ;-)  Backward compatibility _is_ important, but there seems
no way to know in this case whether struct's range-checking sloppiness
was accidental or deliberate.  Having fixed bugs in the old code
several times, and been reduced to writing crap like this in the old
test_struct.py:

    # XXX Most std integer modes fail to test for out-of-range.
    # The "i" and "l" codes appear to range-check OK on 32-bit boxes, but
    # fail to check correctly on some 64-bit ones (Tru64 Unix + Compaq C
    # reported by Mark Favas).
    BUGGY_RANGE_CHECK = "bBhHiIlL"

I can't help but note several things:

- If it _was_ intended that range-checking be sloppy, nobody
  bothered to document it.

- Or even to write a comment in the code explaining that obscure
  intent.

- When I implemented the Q (8-byte int) format code, I added
  correct range-checking in all cases, and nobody ever complained
  about that.

- As noted in the comment above, we have gotten complaints about
  failures of struct range-checking at other integer widths.

OTOH,  BUGGY_RANGE_CHECK existed because I was too timid to risk
making broken user code visibly broken.

So, in all, I'm 95% sure 2.4's behavior is buggy, but 50% unsure that
we need to warn about it before repairing it.  Since you (Thomas) want
warnings, and in theory it only affects the lightly-used "standard"
modes, I do lean in favor of leaving the standard modes that _are_
broken (as above, not all are) broken in 2.5 but warning that this
will change in 2.6.