This is the mail archive of the
mailing list for the GCC project.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Warren D Smith <warren dot wds at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 26 Jul 2016 14:52:27 +0100
- Subject: Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
- Authentication-results: sourceware.org; auth=none
- References: <CAAJP7Y3cHYEOpdhZUXF1PZAJ=vkKoozRiPgwm2V_jH_T63XTKw@mail.gmail.com>
On 26 July 2016 at 14:31, Warren D Smith wrote:
> 1. Gcc with stdint.h already
> provides such nice predefined types as uint8_t.
> Sizes provided are 8,16,32, and 64.
> In some sense uint1_t is available too (stdbool.h)
> but at least on my machine stdbool uses 8-bits to store a bool,
Because that's the smallest addressable unit.
> e.g. an array of 1000 bools takes 8000 bits,
> which is asinine and kind of defeats the point.
If you want 1000 boolean values then don't use 1000 bool variables, do
something like std::bitset or std::vector<bool> in C++, i.e. create an
array of some integer type and write functions for accessing
> I suggest adding uint1_t, uint2_t and uint4_t support
> to gcc, and packed.
You can't have a variable of a single bit, because you can't address it.
You can have smaller-than-a-byte variables as bitfields inside
structs, but you don't need a typedef for that.
> 128 would be nice too.
GCC already supports __int128 and __uint128 where possible.
> It is obnoxious and arbitrary that only 8,16,32,64 are available,
It's obviously not arbitrary, it's dictated by the hardware.
> and it is a pain to make programmers continually
> have to reinvent the wheel to implement packed nybbles, etc --
> and even when I do so, then my implementation results in ugly
> code, different than the nice-looking code for packed bytes.
> Why not allow me to write uniform code? Why not catch up
> to freaking PASCAL from 40 years ago, which already
> provided packed arrays? This ought to be pretty trivial given
> that you already did 8,16,32,64 to do 1,2,4 also.
> 2. Gcc already provides a way to produce quotient and remainder
> simultaneously, producing a struct with two fields as output:
> div_t x = div(a,b); causes x.quot = a/b, x.rem = a%b.
> Not a lot of people know gcc provides that, but it does, and that is
> good, because
> it provides access to the hardware capability.
GCC doesn't provide that, the C library does, because it's defined by
standard C and has been for decades.