Re: Proposed replacement for 14.4 and C6.2 (interchange encodings)
On Mon, 23 Jun 2014 07:45:40 +0100, John Pryce wrote:
> 1. "... implementation shall provide, for each interchange encoding,
> a standard type signature"
>
> This is meaningless. An implementation doesn't provide concepts, it
> provides means to create and manipulate objects.
I agree. In fact, by the time I got to C6.2 I used different language,
because I was already uncomfortable with the above.
John's suggested replacement is nice.
> 2. Some wording is insufficiently standardese e.g. the several "(assuming
> ...)" comments. I suggest these go into the Note at the end.
Agreed. Let's fix this up.
> 3. From what you said earlier, the \0 null byte seems to be aimed at making
> it easier to decide endianness. But why? don't the initial 8 bytes of
> ASCII tell that?
No, the null byte was just a filler. A single byte cannot be used to detect
Endianness. It was also a minor sop to C, but is not crucial. Perhaps we
can find a better use for it.
> I'm wondering if this byte could be used to distinguish bare from decorated
> interval data.
It could, but as I mentioned in an earlier post, applications need to know
already what type of data they are exchanging, and the signature is only
there to convey platform-dependent encoding details. It is not itself a
descriptive header, but would mosty likely be part of one.
Also, as suggested by Dima and Vincent, most occurrences of "byte" should
be replaced by "octet".
> Attached is my first try at typesetting your proposal (§14.4 only).
Thank you! And while reading it, an omission of mine jumped out at me:
In the example, the bitstring for the decoration needs to be updated
from its old value for "com", 10000000, to the new one, 00010000.
Michel.
---Sent: 2014-06-23 14:25:24 UTC