Date: Sun, 27 Oct 2013 10:12:53 -0700
On Sun, Oct 27, 2013 at 1:06 AM, Jean-Marc Bourguet <jm_at_[hidden]> wrote:
> On 26/10/2013 22:51, John Regehr wrote:
>>> ... there is no
>>> representation change when converting a signed int value to unsigned int
>>> or when converting an unsigned int value to signed int.
>> Wow-- anyone care to guess what fraction of existing C programs run
>> correctly under these conditions?
> Define correctly. Note that they have a switch to get a more conform
> behaviour, but they preferred to provide by default a non-conform
> one,
And AFAICS they didn't bother to implement a C++ compiler at all,
indicating to me that the niche for C is that of being easy to
implement, not that of supporting more machines (since it _doesn't_
support the efficient mode for this machine).
If we make the C++ definition stricter, either unusual machines will
keep implementing just C because it's still easier, or they'll
implement a non-conforming mode for C++ as the default and a
conforming mode as a switch, just like they do for C.
Jeffrey
> On 26/10/2013 22:51, John Regehr wrote:
>>> ... there is no
>>> representation change when converting a signed int value to unsigned int
>>> or when converting an unsigned int value to signed int.
>> Wow-- anyone care to guess what fraction of existing C programs run
>> correctly under these conditions?
> Define correctly. Note that they have a switch to get a more conform
> behaviour, but they preferred to provide by default a non-conform
> one,
And AFAICS they didn't bother to implement a C++ compiler at all,
indicating to me that the niche for C is that of being easy to
implement, not that of supporting more machines (since it _doesn't_
support the efficient mode for this machine).
If we make the C++ definition stricter, either unusual machines will
keep implementing just C because it's still easier, or they'll
implement a non-conforming mode for C++ as the default and a
conforming mode as a switch, just like they do for C.
Jeffrey
Received on 2013-10-27 18:13:15