On May 31, 2006, at 12:49 AM, Neal Norwitz wrote:

Bob,

There are a couple of things I don't understand about the new struct. Below is a test that fails.

$ ./python ./Lib/test/regrtest.py test_tarfile test_struct test_tarfile /home/pybot/test-trunk/build/Lib/struct.py:63: DeprecationWarning: 'l' format requires -2147483648 <= number <= 2147483647 return o.pack(*args) test_struct test test_struct failed -- pack('>l', -2147483649) did not raise error 1 test OK. 1 test failed: test_struct

####

I fixed the error message (the min value was off by one before). I think I fixed a few ssize_t issues too.

The remaining issues I know of are:

• The warning only appears on 64-bit platforms.
• The warning doesn't seem correct for 64-bit platforms (l is 8

bytes, not 4).

• test_struct only fails if run after test_tarfile.
• The msg from test_struct doesn't seem correct for 64-bit platforms.

I tracked the problem down to trying to write the gzip tar file. Can you fix this?

The warning is correct, and so is the size. Only native formats have native sizes; l and i are exactly 4 bytes on all platforms when using =, >, <, or !. That's what "std size and alignment" means.

It looks like the only thing that's broken here is the test. The behavior changed to consistently allow any integer whatsoever to be passed to struct for all formats (except q and Q which have always done proper range checking). Previously, the range checking was inconsistent across platforms (32-bit and 64-bit anyway) and when using int vs. long.

Unfortunately I don't have a 64-bit platform easily accessible and I have no idea which test it is that's raising the warning. Could you isolate it?

-bob

[Bob]

...

The warning is correct, and so is the size. Only native formats have native sizes; l and i are exactly 4 bytes on all platforms when using =, >, <, or !. That's what "std size and alignment" means.

[Neal]

Ah, you are correct. I see this is the behaviour in 2.4. Though I wouldn't call 4 bytes a standard size on a 64-bit platform.

"standard" is a technical word with precise meaning here, and is defined by the struct module docs, in contrast to "native". It means whatever they say it means :-) "Portable" may have been a more intuitive word than "standard" here -- read "standard" in the struct context in the sense of "standardized, regardless of native platform size or alignment or endian quirks".

Would someone augment the warnings module to make testing more reasonable?

What's required? I know of two things:

1. There's no advertised way to save+restore the internal filter list, or to remove a filter entry, so tests that want to make a temporary change have to break into the internals.

2. There's no advertised way to disable "only gripe once per source line" behavior. This gets in the way of testing that warnings get raised when running tests more than once, or using a common function to raise warnings from multiple call sites.

These get in the way of Zope and ZODB testing too, BTW. Unfortunately, looks like the new test_struct code bumped into both of them at once.

On 5/31/06, Tim Peters tim.peters@gmail.com wrote:

"standard" is a technical word with precise meaning here, and is defined by the struct module docs, in contrast to "native". It means whatever they say it means :-) "Portable" may have been a more intuitive word than "standard" here -- read "standard" in the struct context in the sense of "standardized, regardless of native platform size or alignment or endian quirks".

:-)

...

Would someone augment the warnings module to make testing more reasonable?

What's required? I know of two things:

1. There's no advertised way to save+restore the internal filter list, or to remove a filter entry, so tests that want to make a temporary change have to break into the internals.

2. There's no advertised way to disable "only gripe once per source line" behavior. This gets in the way of testing that warnings get raised when running tests more than once, or using a common function to raise warnings from multiple call sites.

These get in the way of Zope and ZODB testing too, BTW. Unfortunately, looks like the new test_struct code bumped into both of them at once.

Right. The 2 you list above are the only one's I know of.

You fixed one of them. I find the __warningregistry__ fix extremely obscure. I remember working on wrt test_warnings (and -R maybe?). I don't think I fixed, someone else eventually figured it out, probably you. :-)

n