MacOS Extension Carbon.File.FSCatalogInfo file sizes should be UInt64?

[donbro]

If my read of the extension source (Mac/Modules/file/_Filemodule.c) is
correct, the parameter sizes specified for data and resource file sizes
are UInt32 where they should be UInt64.

In both OS9 and OSX Carbon, the MacOS File Manager (Files.h) uses
UInt64 values for data and resource filesizes.

Testing Python 2.3 and 2.4.2 on MacOS 10.3 returns 0L for the file size
values and correct values for other elements such as parentDirID:

fsRef = FSRef('LICENSE')
catinfo, d1, d2, d3 = fsRef.FSGetCatalogInfo(-1L)
catinfo.dataPhysicalSize 0 catinfo.parentDirID

2026177
in Files.h, both OS9 and OSX Carbon, the elements are UInt64:

struct FSCatalogInfo {
[...]
UInt64 dataLogicalSize;
UInt64 dataPhysicalSize;
UInt64 rsrcLogicalSize;
UInt64 rsrcPhysicalSize;
[...]
}

in _Filemodule.c the spec looks to be 32 bit:

static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoOb ject
*self, void *closure)
{
return Py_BuildValue("l", self->ob_itself.dataLogicalSize);
}

I have, perhaps naively, just changed my local copy to use a BuildValue
parameter of "L" instead of "l" for each of these get and set methods
and this has survived my initial testing:

static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoOb ject
*self, void *closure)
{
return Py_BuildValue("L", self->ob_itself.dataLogicalSize);
}

But my questions are:

Has anyone else seen this?

Does this seem like the right fix?

There is another routine in _Filemodule.c: FSCatalogInfo_tp_init() that
also seems to hold information relevant to parameter size. Should this
be changed as well?

If this is a bug, what's the best procedure to report this?
Sourceforge? This mailing list?

I'm porting a MacOS9 application from C++ to python and I expect to be
seeing a lot of these python macintosh filesystem extensions in the
near future!

Thanks for any help

Don

[Kevin Walzer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

donbro wrote:
| If my read of the extension source (Mac/Modules/file/_Filemodule.c) is
| correct, the parameter sizes specified for data and resource file sizes
| are UInt32 where they should be UInt64.
|
| In both OS9 and OSX Carbon, the MacOS File Manager (Files.h) uses
| UInt64 values for data and resource filesizes.
|
| Testing Python 2.3 and 2.4.2 on MacOS 10.3 returns 0L for the file size
| values and correct values for other elements such as parentDirID:
|
|
|>>>fsRef = FSRef('LICENSE')
|>>>catinfo, d1, d2, d3 = fsRef.FSGetCatalogInfo(-1L)
|>>>catinfo.dataPhysicalSize
|
| 0
|
|>>>catinfo.parentDirID
|
| 2026177
|
|
| in Files.h, both OS9 and OSX Carbon, the elements are UInt64:
|
| struct FSCatalogInfo {
| [...]
| UInt64 dataLogicalSize;
| UInt64 dataPhysicalSize;
| UInt64 rsrcLogicalSize;
| UInt64 rsrcPhysicalSize;
| [...]
| }
|
| in _Filemodule.c the spec looks to be 32 bit:
|
| static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoOb ject
| *self, void *closure)
| {
| return Py_BuildValue("l", self->ob_itself.dataLogicalSize);
| }
|
| I have, perhaps naively, just changed my local copy to use a BuildValue
| parameter of "L" instead of "l" for each of these get and set methods
| and this has survived my initial testing:
|
| static PyObject *FSCatalogInfo_get_dataLogicalSize(FSCatalogInfoOb ject
| *self, void *closure)
| {
| return Py_BuildValue("L", self->ob_itself.dataLogicalSize);
| }
|
| But my questions are:
|
| Has anyone else seen this?
|
| Does this seem like the right fix?
|
| There is another routine in _Filemodule.c: FSCatalogInfo_tp_init() that
| also seems to hold information relevant to parameter size. Should this
| be changed as well?
|
| If this is a bug, what's the best procedure to report this?
| Sourceforge? This mailing list?
|
| I'm porting a MacOS9 application from C++ to python and I expect to be
| seeing a lot of these python macintosh filesystem extensions in the
| near future!
|
| Thanks for any help
|
| Don
|
You're most likely to get a good answer to this question on the
MacPython mailing list--give that a try if you don't get a response here.
- --
Cheers,

Kevin Walzer, PhD
WordTech Software - "Tame the Terminal"
http://www.wordtech-software.com
sw at wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDZmj8JmdQs+6YVcoRAtkTAJ9CEYbIRy6VLY7qp304JP mcl+iXUQCdHTMT
KmJljW7loFJNKFsjFkB2aNA=
=vEVV
-----END PGP SIGNATURE-----

[donbro]

Kevin,

Thanks for the tip. I'll post this to the pythonmac-sig mailing
list.

Don