llvm dev - May 2019 - RFC: On removing magic numbers assuming 8-bit bytes

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF
> Bastien via llvm-dev
> 
> I’m not a fan of C and C++ supporting anything but 8 bits per byte.
> Realistically, C and C++ on such targets are different languages from 8-
> bit-per-byte C and C++, and therefore code isn’t portable from one to the
> other.
Having done it, I promise you that it's reasonable to write portable C
targeting both 7-bit and 8-bit 'char'.  It was too long ago to remember
anything in detail, but the brain cells still remaining from that era
believe it was pretty clean.
> I intend to propose that C++23 support only 8 bits per byte, ditto
> C. I’m therefore not a fan of teaching clang about this.
My impression is that non-8-bit-byte machines are (these days) generally 
small and likely for embedded or other special purposes, so a proposal 
to stop trying to squeeze the bloated monster that C++ has become onto 
those is probably fine. C, on the other hand, appears to be the language
of choice for all sorts of weird things, and that's less likely to fly.
(Just sayin'. I'm not on either committee and have no vested interest.)
--paulr

> On May 2, 2019, at 10:21 AM, paul.robinson at sony.com wrote:
> 
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
JF
>> Bastien via llvm-dev
>> 
>> I’m not a fan of C and C++ supporting anything but 8 bits per byte.
>> Realistically, C and C++ on such targets are different languages from
8-
>> bit-per-byte C and C++, and therefore code isn’t portable from one to
the
>> other.
> 
> Having done it, I promise you that it's reasonable to write portable C
> targeting both 7-bit and 8-bit 'char'.  It was too long ago to
remember
> anything in detail, but the brain cells still remaining from that era
> believe it was pretty clean.
I agree it’s *possible*, same way I’ve seen some correct uses of volatile, and
the same way I’m sure some code supported non-two’s-complement machines
correctly. What I’m saying is that most code simply isn’t, often in subtle ways.
The code you wrote is therefore a subset of C which is incompatible with C at
large.

>> I intend to propose that C++23 support only 8 bits per byte, ditto
>> C. I’m therefore not a fan of teaching clang about this.
> 
> My impression is that non-8-bit-byte machines are (these days) generally 
> small and likely for embedded or other special purposes, so a proposal 
> to stop trying to squeeze the bloated monster that C++ has become onto 
> those is probably fine. C, on the other hand, appears to be the language
> of choice for all sorts of weird things, and that's less likely to fly.
> (Just sayin'. I'm not on either committee and have no vested
interest.)
> --paulr
>

I don't think it was really that severe of a "subset" and would
dispute that a "subset" is inherently "incompatible" but
that
is straying too far from the topic at hand to tolerate.
--paulr
> -----Original Message-----
> From: jfbastien at apple.com [mailto:jfbastien at apple.com]
> Sent: Thursday, May 02, 2019 1:25 PM
> To: Robinson, Paul
> Cc: jesper.antonsson at ericsson.com; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] RFC: On removing magic numbers assuming 8-bit
> bytes
> 
> 
> 
> > On May 2, 2019, at 10:21 AM, paul.robinson at sony.com wrote:
> >
> >> -----Original Message-----
> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of JF
> >> Bastien via llvm-dev
> >>
> >> I’m not a fan of C and C++ supporting anything but 8 bits per
byte.
> >> Realistically, C and C++ on such targets are different languages
from
> 8-
> >> bit-per-byte C and C++, and therefore code isn’t portable from one
to
> the
> >> other.
> >
> > Having done it, I promise you that it's reasonable to write
portable C
> > targeting both 7-bit and 8-bit 'char'.  It was too long ago to
remember
> > anything in detail, but the brain cells still remaining from that era
> > believe it was pretty clean.
> 
> I agree it’s *possible*, same way I’ve seen some correct uses of volatile,
> and the same way I’m sure some code supported non-two’s-complement
> machines correctly. What I’m saying is that most code simply isn’t, often
> in subtle ways. The code you wrote is therefore a subset of C which is
> incompatible with C at large.
> 
> 
> >> I intend to propose that C++23 support only 8 bits per byte, ditto
> >> C. I’m therefore not a fan of teaching clang about this.
> >
> > My impression is that non-8-bit-byte machines are (these days)
generally
> > small and likely for embedded or other special purposes, so a proposal
> > to stop trying to squeeze the bloated monster that C++ has become onto
> > those is probably fine. C, on the other hand, appears to be the
language
> > of choice for all sorts of weird things, and that's less likely to
fly.
> > (Just sayin'. I'm not on either committee and have no vested
interest.)
> > --paulr
> >