[OSC_dev] Developer's list for the OpenSound Control (OSC) Protocol

[Ross Bencina]

Hi All,

I have a question about field size limits in OSC. I'm trying to work out
where to use std::size_t in the oscpack interface (for 64 bit
compatibility), and where it might be more semantically correct to use
int32 or uint32.

The OSC spec (http://opensoundcontrol.org/spec-1_0) describes size
fields (bundle-element size field, blob size field) as int32 -- a signed
value.

Could someone please confirm whether or not the following statements are
correct:

- Given that <bundle-element size> and <blob size> fields are signed
int32, these fields MUST NOT have negative values (ie the highest value
bit of the 32 bit word MUST be zero).

- Given that a <bundle-element size> field is required to be a multiple
of 4, and is a signed int32, the maximum legal value of a bundle-element
size field is 0x7FFFFFFC (and further, must be a multiple of 4).

- Given that a blob size is a signed int32, and blob-data-plus-padding
is required to be 4 byte aligned, the maximum value of a blob size field
is 0x7FFFFFFC (but may take on any positive value in the range).

Thank you,

Ross.

[Matt Wright]

I agree with Ross' first two statements. For the third, I don't see why (in principle) a blob couldn't be of size 0x7FFFFFFF, implying one byte of data padding. But that blob would be too big to put in a bundle, because its data plus its size count would then exceed the bundle maximum size.

Why waste a bit on the semantically invalid possibility of having negative size counts? I believe the reasoning at the time was to minimize the number of numeric types required by the standard, for ease of implementation on embedded systems. Also it seemed that there would be practical limits to transferring (not to mention receiving and processing) even 2GB blobs or bundles, so being able to get up to 4 didn't seem worth the added complexity. I certainly wouldn't suggest an incompatible new version with all 64-bit size counts!

-Matt

Post by Ross Bencina
Hi All,
I have a question about field size limits in OSC. I'm trying to work out
where to use std::size_t in the oscpack interface (for 64 bit
compatibility), and where it might be more semantically correct to use
int32 or uint32.
The OSC spec (http://opensoundcontrol.org/spec-1_0) describes size
fields (bundle-element size field, blob size field) as int32 -- a signed
value.
Could someone please confirm whether or not the following statements are
- Given that <bundle-element size> and <blob size> fields are signed
int32, these fields MUST NOT have negative values (ie the highest value
bit of the 32 bit word MUST be zero).
- Given that a <bundle-element size> field is required to be a multiple
of 4, and is a signed int32, the maximum legal value of a bundle-element
size field is 0x7FFFFFFC (and further, must be a multiple of 4).
- Given that a blob size is a signed int32, and blob-data-plus-padding
is required to be 4 byte aligned, the maximum value of a blob size field
is 0x7FFFFFFC (but may take on any positive value in the range).
Thank you,
Ross.
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev