From: already5chosen@yahoo.com   
      
   On Tue, 25 Nov 2025 14:57:17 +0000   
   bart  wrote:   
      
   > On 25/11/2025 12:12, Michael S wrote:   
   > > On Tue, 25 Nov 2025 11:38:32 +0000   
   > > bart  wrote:   
   > >   
   > >>   
   > >> No, apart from the usual set of 8/16/32/64 bits. I've done 128   
   > >> bits, and played with 1/2/4 bits, but my view is that above this   
   > >> range, using exact bit-sizes is the wrong way to go.   
   > >>   
   > >   
   > > Either that or manifestation of your NIH syndrome.   
   > > Which explanation do you consider more likely?   
   >   
   > I can invent anything I like. I've looked at such things many times,   
   > and came to the conclusion that using types is the wrong approach,   
   > certainly for this level of language.   
   >   
   > (Yes, long ago I allowed type denotations such as:   
   >   
   >       int*N a          a has N bytes or N*8 bits (from Fortran)   
   >       int:N b          b has N bits   
   >   
   > Then I realised I was never going to use anything other than some   
   > power-of-two size of 8 bits or more, for discrete variables.)   
   >   
   >   
   > >   
   > >> While for odd sizes up to 64 bits, bitfields are more apt than   
   > >> employing the type system.   
   > >>   
   > >   
   > > int sign_extend12(unsigned x)   
   > > {   
   > >    return (_BitInt(12))x;   
   > > }   
   > >   
   > > Nice, is not it?   
   >   
   > By 'bitfields' I mean bitfields within structs, but also bitfield   
   > operators whch work on any integer values.   
   >   
   > Bitfields are nearly always unsigned in my projects, so I don't have   
   > an exact equivalent to this example.   
   >   
   > But a solution not using types would look like this:   
   >   
   >      y := x.[0..11]           # get first 12 bits   
   >      y := x.[12..23]          # next 12 bits   
   >   
   >      x.[24..35] := y          # set next 12 bits (x, y are 64 bits!)   
   >   
   >      y := x.[0..i]            # get first i+1 bits   
   >   
   > To optionally interpret a bitfield extraction as signed, I'd need to   
   > think up some way of denoting that. For bitfield insertion it doesn't   
   > matter.   
   >   
   > Your example is interesting but rather limited; while it does deal   
   > with a signed field:   
   >   
   > * That field can only start at bit zero, without extra manipulations   
   >   
   > * The size is fixed at 12 (if you decide to change the field size, or   
   >    you want it as a constant parameter somewhere, it starts getting   
   >    awkward)   
   >   
   > * If you are dealing with a range of bitfield sizes, you will need a   
   >    dedicated function, or somehow enumerate all possibilities using   
   >    _Generic.   
   >   
   > * It's not clear how bitfield insertion would work, whether you'd   
   > still employ a _BitInt type, and/or just revert to those shifts and   
   > masks.   
   >   
   >   
   >   
      
   My example is from real world. Dealing with A-to-D converters. I need   
   sign extension of that sort quite often.   
   * I don't recollect needing to sign-extend field that does not start at   
   offset zero, but if it happens then logical left shift [before cast] is   
   an obvious and natural solution.   
   * My ADCs have fixed # of bits. It does not change in the middle of   
   project. And even if it does then a new value is also fixed, so   
   constant (enum or define) works fine.   
   Same for your other points - I don't recollect that I neeed something   
   like that sufficiently often to ... well... recollect.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)