From: david.brown@hesbynett.no   
      
   On 02/12/2025 22:17, Philipp Klaus Krause wrote:   
   > Am 01.12.25 um 21:42 schrieb Keith Thompson:   
   >>   
   >> But given that several compilers have already implemented bit-precise   
   >> integer types *without* either allowing N > BITINT_MAXWDITH or   
   >> disallowing "odd" values, I don't think it will be an issue in   
   >> practice.   
   >>   
   >   
   > There are extensions regarding _BitInt in existing implementations: SDCC   
   > allows signed _BitInt(1), and allows the use of _BitInt as underlying   
   > type for enum.   
      
   These both seem good extensions to me.  I don't know why _BitInt(1) was   
   explicitly disallowed in C.  It is arguably a fairly useless type   
   (holding values 0 and -1), but it would seem simpler for the standard to   
   allow it and keeping things symmetric, rather than have to make   
   "unsigned _BitInt(1)" explicitly allowed.  Since it seems likely that   
   C++ will allow _BitInt(1) when it adopts them (with C++ templates,   
   sometimes "useless" types become very convenient), it would not surprise   
   me if a later C standard includes them for consistency.  (But there may   
   be good reasons for disallowing the type that I have not thought of.)   
      
   I also think it makes a lot of sense to allow _BitInt types as the   
   explicitly specified underlying type for enums - I don't know why they   
   are disallowed.  There may be some reasoning involving how enumerations   
   or their constants can be used elsewhere, but I can't see what.  If it   
   were just a matter of avoiding complications in implementations, then   
   their support could have been made optional here.   
      
   > In --std-c23 mode, SDCC will emit a warning when encountering those, but   
   > the semantics are of course the same as in --std-sdcc23 mode.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)