<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">James W Thomas <<a href="mailto:jaswthomas@sbcglobal.net">jaswthomas@sbcglobal.net</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: (SC22WG14.12931) Reset for TS 18661 Part 3?</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">June 4, 2013 9:47:47 AM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">"Joseph S. Myers" <<a href="mailto:jsm@polyomino.org.uk">jsm@polyomino.org.uk</a>>, SC22 WG14 <<a href="mailto:sc22wg14@open-std.org">sc22wg14@open-std.org</a>><br></span></div><br><div>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.<br><br>Any objections to adding 8-bit bytes as a conformance requirement for Parts 2 and 3? <br><br>-Jim Thomas<br><br><br>On May 21, 2013, at 5:13 PM, Joseph S. Myers <<a href="mailto:jsm@polyomino.org.uk">jsm@polyomino.org.uk</a>> wrote:<br><br><blockquote type="cite">On Sat, 11 May 2013, James W Thomas wrote:<br><br><blockquote type="cite">1. Replace data-interchange types with data-interchange encodings. (We <br>already have these for decimal.)<br></blockquote><br>The following comment is a bit late, but it applies just as much to the <br>encodings that are in Part 2 as to anything that may happen to define <br>types in Part 3 as corresponding to particular encodings.<br><br>If you define a type corresponding to an encoding, like <br>decencodingd{32,64,128}_t and binencodingd{32,64,128}_t, for this type to <br>be useful for the intended interchange purpose it must be possible to <br>exchange data in that type reliably between implementations (e.g. writing <br>it to files that can then be read by other implementations).<br><br>The encodings in IEEE 754-2008 are specified as bit-strings with a defined <br>MSB and LSB. C types are encoded in terms of bytes, which need not be <br>eight bits (thus the inappropriateness of the existing references to <br>octets in Part 2, which I've previously mentioned). For effective <br>interchange, programs need to be able to determine the mapping between <br>the bit-strings of the IEEE floating-point encodings, and the bytes of the <br>encodings used in C.<br><br>Most practical cases would I think be covered by giving a way (i.e. a <br>macro in a header) for the implementation to say whether encodings are <br>big-endian or little-endian - with the additional requirement that <br>implementations of the relevant Parts of the TS must have 8-bit bytes <br>(otherwise you also need to say something about partially used bytes, e.g. <br>that there are padding bits whose values are not significant at the MSB <br>end of the number).<br><br>There are of course variant approaches possible, e.g. defining all <br>functions relating to encodings to work with arrays of sufficiently many <br>unsigned char rather than using special types at all, in which case you <br>could allow the user to specify the endianness explicitly (you still have <br>the padding question if the byte size doesn't exactly divide the sizes of <br>all relevant types). (With this approach, it would also be possible to <br>reduce the number of functions by making the number of bits in the format <br>an argument to the functions rather than having different functions for <br>each number of bits.)<br><br>-- <br>Joseph S. Myers<br><a href="mailto:joseph@codesourcery.com">joseph@codesourcery.com</a><br></blockquote><br></div></blockquote></div><br></body></html>