From: already5chosen@yahoo.com   
      
   On Tue, 25 Nov 2025 18:33:30 +0000   
   bart  wrote:   
   >   
   >  > * I don't recollect needing to sign-extend field that does not   
   >  > start   
   > at> offset zero,   
   >   
   > So what's in the rest of the 32-bit field, garbage?   
   >   
      
   Either garbage or zero or, rarely there could be meaningful flags.   
   I don't see how the question is relevant.   
      
   >   
   > > Same for your other points - I don't recollect that I neeed   
   > > something like that sufficiently often to ... well... recollect.   
   >   
   > Yours is one of a thousand possible applications. Everyone will have   
   > different needs. Maybe someone else will have a 16 or 32-bit value   
   > with assorted bitfields of different widths.   
   >   
   > Then maybe C bitfields could be used, but a bigger problem with those   
   > is poor control over layout, which is anyway implementation-defined.   
   > (Mine of course don't have that problem!)   
      
   According to the language of The Standard, it's not 'poor control'.   
   As far as standard requirements goes, there is *no* control on layout of   
   bit fields.   
   Of course, implementer is encouraged to specify exact rules in his   
   documents. In many (not all) cases bitfield layout is part of the ABI,   
   so it is shared by all compilers on given platform. But that does not   
   exactly help people that don't like reading ABI docs or compiler   
   manuals. Also does not help those poor souls that try to write portable   
   code.   
      
   Shifts and masks provide much more solid ground.   
   And combination of shifts with _BitInt() appears equally solid, but   
   more convenient and more self-documenting.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)