[Cfp-interest] Fwd: (SC22WG14.12931) Reset for TS 18661 Part 3?

[James W Thomas]

Begin forwarded message:

> From: James W Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: (SC22WG14.12931) Reset for TS 18661 Part 3?
> Date: June 4, 2013 9:47:47 AM PDT
> To: "Joseph S. Myers" <jsm at polyomino.org.uk>, SC22 WG14 <sc22wg14 at open-std.org>
> 
> We didn't intend to address endianness, believing it to be a more general language issue. Note that IEC 60559 did not specify endianness, nor a way to deal with it.
> 
> Any objections to adding 8-bit bytes as a conformance requirement for Parts 2 and 3? 
> 
> -Jim Thomas
> 
> 
> On May 21, 2013, at 5:13 PM, Joseph S. Myers <jsm at polyomino.org.uk> wrote:
> 
>> On Sat, 11 May 2013, James W Thomas wrote:
>> 
>>> 1. Replace data-interchange types with data-interchange encodings. (We 
>>> already have these for decimal.)
>> 
>> The following comment is a bit late, but it applies just as much to the 
>> encodings that are in Part 2 as to anything that may happen to define 
>> types in Part 3 as corresponding to particular encodings.
>> 
>> If you define a type corresponding to an encoding, like 
>> decencodingd{32,64,128}_t and binencodingd{32,64,128}_t, for this type to 
>> be useful for the intended interchange purpose it must be possible to 
>> exchange data in that type reliably between implementations (e.g. writing 
>> it to files that can then be read by other implementations).
>> 
>> The encodings in IEEE 754-2008 are specified as bit-strings with a defined 
>> MSB and LSB.  C types are encoded in terms of bytes, which need not be 
>> eight bits (thus the inappropriateness of the existing references to 
>> octets in Part 2, which I've previously mentioned).  For effective 
>> interchange, programs need to be able to determine the mapping between 
>> the bit-strings of the IEEE floating-point encodings, and the bytes of the 
>> encodings used in C.
>> 
>> Most practical cases would I think be covered by giving a way (i.e. a 
>> macro in a header) for the implementation to say whether encodings are 
>> big-endian or little-endian - with the additional requirement that 
>> implementations of the relevant Parts of the TS must have 8-bit bytes 
>> (otherwise you also need to say something about partially used bytes, e.g. 
>> that there are padding bits whose values are not significant at the MSB 
>> end of the number).
>> 
>> There are of course variant approaches possible, e.g. defining all 
>> functions relating to encodings to work with arrays of sufficiently many 
>> unsigned char rather than using special types at all, in which case you 
>> could allow the user to specify the endianness explicitly (you still have 
>> the padding question if the byte size doesn't exactly divide the sizes of 
>> all relevant types).  (With this approach, it would also be possible to 
>> reduce the number of functions by making the number of bits in the format 
>> an argument to the functions rather than having different functions for 
>> each number of bits.)
>> 
>> -- 
>> Joseph S. Myers
>> joseph at codesourcery.com
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130604/ed2c5f5b/attachment.html