That's all well and good, but having a type "bit" type that means the same thing in both cases, leads to equivalent generated code in both cases, would be good language design. I accept that C can do many things when these idiosyncrasies are understood, I just disapprove of them being idiosyncratic.

I mean if "unsigned <identifier> : <integer>" really means bit why can't one declare a local variable as that type? The "bit" notation is only allowed inside a struct!

In fact, that the bit positions must be hardcoded breaks the abstraction and the generality of the code. While sometimes I would like to know the actual bit positions (which should be an option), normally I'd rather the compiler just string together bits as necessary in the order they are declared, also adding additional bytes as necessary.

 

That's all well and good, but having a type "bit" type that means the same thing in both cases, leads to equivalent generated code in both cases, would be good language design. I accept that C can do many things when these idiosyncrasies are understood, I just disapprove of them being idiosyncratic.

I mean if "unsigned <identifier> : <integer>" really means bit why can't one declare a local variable as that type? The "bit" notation is only allowed inside a struct!

It's because at the real hardware level (something C was designed for) you rarely need to manipulate 1 bit in total isolation with bit level addressing. You manipulate 1 bit or more bits within in a byte defined register address. So bit notation at the byte/word structure level matches actual hardware in the C abstract machine design.

 

In fact, that the bit positions must be hardcoded breaks the abstraction and the generality of the code. While sometimes I would like to know the actual bit positions (which should be an option), normally I'd rather the compiler just string together bits as necessary in the order they are declared, also adding additional bytes as necessary.

Yes, there are cases where we want a bunch of bits with no regard to their relative positions, unless we're representing some existing bit level layout.

Bits very naturally fit the array pattern, so declaring and accessing them as an array is sometimes a natural thing to do, alas C offers us no such capability, we can't - for example - do this:

struct bit_flags
{
    uint8_t flags[8] : 1;
}

or

struct bit_flags
{
    uint8_t flags : 1 [8];
}

Which would let us write:

bits.flags[2] = false;
bits.flags[3] = true;

for (int X=0; X < 8; X++)
{
    bits.flags[X] = get_status(X);
}

and so on, I'd argue there's even a case for a "nybble" type here.

 

It's because at the real hardware level (something C was designed for) you rarely need to manipulate 1 bit in total isolation with bit level addressing. You manipulate 1 bit or more bits within in a byte defined register address. So bit notation at the byte/word structure level matches actual hardware in the C abstract machine design.

In my world, a "flag" or semaphore is a thing -- and should be abstracted away from bits and bytes.

 

In fact, that the bit positions must be hardcoded breaks the abstraction and the generality of the code. While sometimes I would like to know the actual bit positions (which should be an option), normally I'd rather the compiler just string together bits as necessary in the order they are declared, also adding additional bytes as necessary.

For that normally you would use C bit-wise manipulations with bit-masks on the byte/word.
https://www.learn-c.org/en/Bitmasks

 

In my world, a "flag" or semaphore is a thing -- and should be abstracted from bits and bytes.

C easily provides that capability without the need for a BIT type abstraction. The fact the BIT type abstraction is missing from a language designed and used to program very efficient and complex OS level programs like Linux means it is redundant at the C source level.

 

C easily provides that capability without the need for a BIT abstraction.

...should be abstracted away from bits and bytes.

BECAUSE then the compiler can take advantage of the specifics of the target hardware to produce the best optimized code for that target.

 

BECAUSE then the compiler can take advantage of the specifics of the target hardware to produce the best optimized code for that target.

It's a mixed bag. The best optimized code for that target is often not the code with the least number of instructions. Never trust the compiler to sequence tricky and sometimes, to a compiler redundant, command sequences to hardware.

 

It's because at the real hardware level (something C was designed for)

Except C was not designed for hardware level code development, it was designed for simplicity and ease of implementation, if it was designed at all, I'm happy to retract this if you have some historic basis for it, but it really isn't the origin of C at all from what I've read.

Unix is written in C (and that was its core motivation, to write and OS in a high level language that was not itself too hard to implement), yet 99% of the OS code "sees" no hardware at all, only small device driver layers might access hardware.

you rarely need to manipulate 1 bit in total isolation with bit level addressing. You manipulate 1 bit or more bits within in a byte defined register address. So bit notation at the byte/word structure level matches actual hardware in the C abstract machine design.

A bit, a nybble, a byte, a word, a double, a pointer, a struct, a function are all abstractions, they can exist individually or as a multiplicity, they really can. The abstraction of a 2D array of bits, say 16x16 might very naturally arise in some problem domains, to declare and manipulate such an abstraction should require no different syntax than any other 2D array.

 

Except C was not designed for hardware level code development, it was designed for simplicity and ease of implementation, if it was designed at all, I'm happy to retract this if you have some historic basis for it, but it really isn't the origin of C at all from what I've read.

Unix is written in C (and that was its core motivation, to write and OS in a high level language that was not itself too hard to implement), yet 99% of the OS code "sees" no hardware at all, only small device driver layers might access hardware.



A bit, a nybble, a byte, a word, a double, a pointer, a struct, a function are all abstractions, they can exist individually or as a multiplicity, they really can. The abstraction of a 2D array of bits, say 16x16 might very naturally arise in some problem domains, to declare and manipulate such an abstraction should require no different syntax than any other 2D array.

Software guys, we love them and the ivory tower they live in.

 

Software guys, we love them and the ivory tower they live in.

Speaking of towers, I collect the limited edition prints of Robert Tinney's old Byte magazine cover art, superbly creative individual.

​

What was never clear is whether the folks in the balloon were at last escaping the ivory tower or perhaps happily escaping to it!

 

What was never clear is whether the folks in the balloon were at last escaping the ivory tower or perhaps happily escaping to it!

Neither. Their cries for help fell on deaf ears.

 

I have some original Kilobaud magazines somewhere.
https://archive.org/details/kilobaudmagazine



Less abstraction on the covers.

 

I have some original Kilobaud magazines somewhere.
https://archive.org/details/kilobaudmagazine

View attachment 280357

Less abstraction on the covers.

If the C language was built from hardware:

 

Without that type of hardware mess in the early days your present day computer would not exist for programming because today's senior hardware engineers wrote the books on today's chip manufacturing architectures.

 

In 1971...

Damn. Your older than me, and I'm older than dirt.

Nice you keep so intellectually active.

 

Damn. Your older than me, and I'm older than dirt.

Nice you keep so intellectually active.

Oops, cross posting in the message buffer. Fixed.

 

Damn. Your older than me, and I'm older than dirt.

Nice you keep so intellectually active.

Is your code open source? how do you back it up and manage changes?

 

Is your code open source? how do you back it up and manage changes?

Open source: no. All hardware and code is mine and top secret -- except for the snippets I show here. No 3rd party libraries -- I don't trust (or should I say, "have faith in") other programmers.

I run and manage my own local and remote file servers . I don't trust the cloud and the would-be masters-of-the-universe who run them.

Snapshots of my file servers are captured off-site daily onto backup servers which I also own and manage using backup code I wrote myself. The daily snapshots are kept in perpetuity.

Disparate locations are connected via my custom routers running OpenVPN, which I also run and manage.

Heck, I even run my own voip phone system.

I use git for version control.

My documentation control system is also home grown, running on a LAMP server (Linux, Apache, MariaDB, PHP).

Linux rules my roost. Nary a Windows or Mac machine to be found.

 

Open source: no. All hardware and code is mine and top secret -- except for the snippets I show here. No 3rd party libraries -- I don't trust (or should I say, "have faith in") other programmers.

I run and manage my own local and remote file servers . I don't trust the cloud and the would-be masters-of-the-universe who run them.

Snapshots of my file servers are captured off-site daily onto backup servers which I also own and manage using backup code I wrote myself. The daily snapshots are kept in perpetuity.

Disparate locations are connected via my custom routers running OpenVPN, which I also run and manage.

Heck, I even run my own voip phone system.

I use git for version control.

My documentation control system is also home grown, running on a LAMP server (Linux, Apache, MariaDB, PHP).

Linux rules my roost. Nary a Windows or Mac machine to be found.

Well sounds like you have stuff covered, but do test your setup, be sure that if a catastrophe does strike you you can indeed recover from the backups and stuff. Much of the time this disaster survivability goes untested and then...