Imported from previous forum
[ original email was from John Hardman - yiq12@dial.pipex.com ]
Three points/questions re. data fields and length fields;
[1]
The FIX 4.2 specification says the following;
“Data fields are always immediately preceded by a length field. The length field should specify the number of bytes of the value of the data field (up to but not including the terminating SOH”
Would it be possible in the 4.2 errata to explicitly say that these length fields have to be of type int ? For the currently defined fields this is the case, but adding this explicit statement would ensure that user-defined fields follow the same practice.
[2]
It may also be worth considering adding a rule that the length field should have a field id one less than the related data field. This practice is followed in the defined messages, although it may be thought a little restrictive to force this practice for user-defined messages.
[3]
There would appear to be a case for an unsigned int data type, to be used for length fields etc. Is there any intention to add this or would it cause too many systems to break to add it at this stage ?
Many thanks in advance,
John Hardman.
[ original email was from John Hardman - yiq12@dial.pipex.com ]
I have just realised that point [2] was incorrect - there is one field of type data in FIX 4.2 where the field id of the related length field is NOT one less than the field id of the data field. However, would still like to hear about [1] and [3].
> Three points/questions re. data fields and length fields;
>
> [1]
>
> The FIX 4.2 specification says the following;
>
> “Data fields are always immediately preceded by a length field. The length field should specify the number of bytes of the value of the data field (up to but not including the terminating SOH”
>
> Would it be possible in the 4.2 errata to explicitly say that these length fields have to be of type int ? For the currently defined fields this is the case, but adding this explicit statement would ensure that user-defined fields follow the same practice.
>
> [2]
>
> It may also be worth considering adding a rule that the length field should have a field id one less than the related data field. This practice is followed in the defined messages, although it may be thought a little restrictive to force this practice for user-defined messages.
>
> [3]
>
> There would appear to be a case for an unsigned int data type, to be used for length fields etc. Is there any intention to add this or would it cause too many systems to break to add it at this stage ?
>
>
> Many thanks in advance,
>
> John Hardman.
>
>
Regarding your questions:
[1] - I would argue that this already exists. In the Field Reference of the version 4.2 spec, all of the "length fields" (e.g. SecureDataLen (90), RawDataLength(95), etc) are specified to be of data type (column heading is "Format") "int".
[2] - In practice we tend to add these to the spec in this fashion, but I do not see any requirement or value to always making the length field -1 of the data field.
[3] - Within the FIX 4.2 spec’s “Data Types” section the FIX spec data type of “int” is not specific about its size in bytes thus it’s max representation. Creating an “unsigned int” in the FIX spec would effectively create antoher data type with the same definition but non-negative and to the power of 2 in size greater than the existing “int” data type’s length which is not defined. “int” in programming languages tends to be a bit tricky in that it is often machine/platform-dependent (e.g. 16-bit OS=2 bytes, 32-bit OS=4 bytes, etc) with a notable exception of Java. As another example the FIX data type of “float” is defined to be up to 15 significant digits which requires 8 bytes and in many programming languages would be defined as that language’s type “double” (8 byte) vs. “float” (4 byte).
> Three points/questions re. data fields and length fields;
>
> [1]
>
> The FIX 4.2 specification says the following;
>
> “Data fields are always immediately preceded by a length field. The length field should specify the number of bytes of the value of the data field (up to but not including the terminating SOH”
>
> Would it be possible in the 4.2 errata to explicitly say that these length fields have to be of type int ? For the currently defined fields this is the case, but adding this explicit statement would ensure that user-defined fields follow the same practice.
>
> [2]
>
> It may also be worth considering adding a rule that the length field should have a field id one less than the related data field. This practice is followed in the defined messages, although it may be thought a little restrictive to force this practice for user-defined messages.
>
> [3]
>
> There would appear to be a case for an unsigned int data type, to be used for length fields etc. Is there any intention to add this or would it cause too many systems to break to add it at this stage ?
>
>
> Many thanks in advance,
>
> John Hardman.
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> [1] - I would argue that this already exists. In the Field Reference of the version 4.2 spec, all of the "length fields" (e.g. SecureDataLen (90), RawDataLength(95), etc) are specified to be of data type (column heading is "Format") "int".
That’s not what he’s saying. His issue is that it is technically possible for someone to define a user-defined field of type Data, and preceed it with a user-defined length fielf of, say, type Float or String.
I think it would be pointless for anyone to try defining a length field in this way, but it doesn’t hurt to make the requirement explicit.
Also I think we should point out, if we haven’t already, that user-defined fields of type Data generally should not be sent unless your counterparty knows to expect them. FIX is not self-describing about data types. While a FIX engine can represent a user-defined field internally as a string in absence of any pre-configured data typing rules, a FIX engine generally cannot differentiate between a user-defined field of type Data and a malformed message if said Data field can contain SOH’s.