Design a better "C"

[tggzzz]

Don't change C. Don't make a better C. C is the perfect C.

I tend to agree. Throw away C's historic cruft, and make a better tool than C can ever be. (Yes, I am aware of what that doesn't say!).

For this I suffer some loss of safety and correctness but gain the ridiculous amount of power from throwing off the shackles of not being trusted near any of that RAM stuff...

If the results didn't have to be correct, I could have developed it in 1 hour and it would take 1s to run. Code size would be much smaller, too

[madires]

Are today's software developers too lazy to learn and understand their programming languages? Is C insecure because software developers can't be bothered to take care about memory management? After moving to Rust will they start complaining about how cumbersome writing code is and ask for an AI doing their job?

[Feynman]

Well, C has its flaws for sure. But the beast is pretty much tamed with things like coding standards and static analysis tools. In my opinion the only real alternative is C++. It has the same performance and low level capabilities and offers some really helpful additions like the standard-library (std) and compile time features, for example.

The only thing I can imagine is that even in embedded systems multi-core architectures could become the norm where functional languages have clear benefits. But on the other hand it's hard to believe that relatively simple single-core micro-controllers will go away any time soon.

Long story short: C is here to stay.

[tggzzz]

Are today's software developers too lazy to learn and understand their programming languages? Is C insecure because software developers can't be bothered to take care about memory management? After moving to Rust will they start complaining about how cumbersome writing code is and ask for an AI doing their job?

Who cares whether or not someone defines them as "lazy".

C is a language that very few people understand completely. Usually, if you ask a typical C programmer what, say, "volatile" guarantees, they will get it wrong one way or another. Most don't realise that until recently it was impossible to write a threading library in C! Then there are all the "simple" things that trip up many people. Can you, for example, "cast away constness", and why should that be impossible and possible?

[tggzzz]

The only thing I can imagine is that even in embedded systems multi-core architectures could become the norm where functional languages have clear benefits. But on the other hand it's hard to believe that relatively simple single-core micro-controllers will go away any time soon.

Long story short: C is here to stay.

Functional languages aren't a panacea. Try doing I/O in a pure functional language

However, C and especially C++ deserve to be regarded as the new COBOL

[cfbsoftware]

@cfbsoftware: I have considered Oberon actually. There's a lot to like about it. But I think Wirth went a bit too far with it. He removed so much that some things are even clunkier to express than with C.

Could you give me an example of where you think this applies please?

Also, all low-level stuff is supposed to be handled by the SYSTEM module - which is an approach that Wirth always cherished - but it does make writing portable low-level stuff very clunky.

Not ALL the low-level stuff needs to be handled by SYSTEM now. Only the stuff that can lead to obscure problems caused by memory corruption e.g. typecasts, accessing absolute memory addresses etc. Note also that SYSTEM is actually a 'pseudo module'. What looks like a procedure call is, more often than not, inline code. SYSTEM is just there to highlight to the code reader / maintainer that they need to take extra care.

I have looked at other similar languages such as Component Pascal, Modula-3, etc. All are interesting in their own way, but, not quite there. At least for me. though.

Agreed. They are not lightweight enough for embedded development on the more resource-limited microcontrollers that we use with Oberon e.g those with only 32 Kb of RAM.

One thing I often mention and that those languages have: support for modules. This is good. I f*cking want modules.

Agreed++ Explicit qualification of imported module references is a key part of this. Initially it can seem like a PITA but they make life soooo much easier when maintaining code. Those new to programming would not have experienced this. Once you realise that the effort required for software that is designed to last is 10-20% development and 80-90% maintenance it gives you a very different perspective ;-)

[hamster_nz]

However, C and especially C++ deserve to be regarded as the new COBOL

And here was I thinking about how nice COBOL was because the internal data representation matched what is useful to the user, not what is optimal for the computer:

Code: [Select]

       01  SALES-INPUT-DETAIL.
           05 SALES-NUM-IN                  PIC 9(4).
           05 SALES-NAME-IN                 PIC X(20).
           05 SALES-REGION-IN               PIC 9.
           05 QUOTA-CLASS-IN                PIC X.
           05 COMM-CLASS-IN                 PIC 9.
           05 YTD-SALES-IN                  PIC 9(6)V99.
           05 YTD-RETURNS-IN                PIC 9(5)V99.
           05 CURR-SALES-IN                 PIC 9(5)V99.
           05 CURR-RETURNS-IN               PIC 9(4)V99.
           05 FILLER                        PIC X(25).

01  SALES-REPORT-DETAIL.
           05 FILLER                        PIC X(7) VALUE SPACES.
           05 SALES-NUM-OUT                 PIC 9(4).
           05 FILLER                        PIC X(5) VALUE SPACES.
           05 SALES-NAME-OUT                PIC X(20).
           05 FILLER                        PIC X(5) VALUE SPACES.
           05 SALES-REGION-OUT              PIC 9.
           05 FILLER                        PIC X(10) VALUE SPACES.
           05 QUOTA-CLASS-OUT               PIC X.
           05 FILLER                        PIC X(10) VALUE SPACES.
           05 COMM-CLASS-OUT                PIC 9.
           05 FILLER                        PIC X(5) VALUE SPACES.
           05 YTD-SALES-OUT                 PIC $$$$,$$9.99.
           05 FILLER                        PIC X(5) VALUE SPACES.
           05 YTD-RETURNS-OUT               PIC $$$,$$9.99.
           05 FILLER                        PIC X(5) VALUE SPACES.
           05 CURR-SALES-OUT                PIC $$$,$$9.99.
           05 FILLER                        PIC X(5) VALUE SPACES.
           05 CURR-RETURNS-OUT              PIC $$,$$9.99.
           05 FILLER                        PIC X(9) VALUE SPACES.

Wouldn't C be nice if you didn't have to muck around with stupid printf format specifiers...

[tggzzz]

If printf format specifiers are your major problem with C, then either you are an expert or you don't know how little you know

[brucehoult]

Current standard is utterly stupid because it allows arbitrary padding of structs for performance reasons, but does not allow reordering.

What disallows reordering?

[SiliconWizard]

Current standard is utterly stupid because it allows arbitrary padding of structs for performance reasons, but does not allow reordering.

What disallows reordering?

At least one thing AFAIR: the "address" of the first member of a struct must be equal to the address of the struct itself. IIRC, so please correct me if I'm wrong. So at least the first member could not be reordered.

Meaning:

Code: [Select]

struct { int n; .... } S;

&S shall be equal to &S.n, if I'm not mistaken.

Edit: checked in the standard. The following is pretty explicit:

As discussed in 6.2.5, a structure is a type consisting of a sequence of members, whose
storage is allocated in an ordered sequence, and a union is a type consisting of a sequence
of members whose storage overlap.

Edit2: if you're unconvinced the above strictly requires struct members to follow order of declaration (I'll admit it's not completely clear), there's a hint in that the last member of a struct can be a "flexible array" member. It's obvious that such a member could not be reordered. That was in C99...

In C11, things get clearer (so I guess the committee realized older revisions were not fully clear about it):

Within  a  structure  object,  the  non-bit-field  members  and  the  units  in  which  bit-fields
reside have addresses that increase in the order in which they are declared. A pointer to a
structure object, suitably converted, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa.  There may be unnamed
padding within a structure object, but not at its beginning.

As things are, the C standard can't change this. This would break existing code all over the place.
If it introduced the possibility of reordering struct members by compilers, it could be done adding a specific qualifier next to the struct definition, so that wouldn't break existing code. Now of course, you would not be able to use the flexible array thing with this. It would have to be explicitely checked by compilers.

I wouldn't mind having this possibility of relaxing member ordering indeed, that would give compilers opportunities to optimize alignment and total size and would minimize required padding.

[hamster_nz]

If printf format specifiers are your major problem with C, then either you are an expert or you don't know how little you know

My beef (if I really had one) would be that all the basic data types are computer-friendly, not user/application friendly.

If I want to hold all 6-digit positive integers I need to use a uint32_t or equivalent. What's wrong with 3 bytes of BCD? Even the 6502 had a BCD mode!

Or how about support for for fixed-point binary representations? The compiler should have no trouble doing the bookkeeping.

This is why I always think that C99 'complex' data types feels wrong. I mean it is a good idea, and it enables lots of performance enhancements and nice coding, but it doesn't feel like C. It has way too much sophistication about it for C.

Oh, and IMO printf() format specifiers do suck - for example, it is most likely a university-level assignment to correctly print out an integer with commas. But scanf() format specifiers suck twice as hard, so much that I usually resort to writing my own parsers for anything but quick hacks.

[TheCalligrapher]

Current standard is utterly stupid because it allows arbitrary padding of structs for performance reasons, but does not allow reordering.

What disallows reordering?

The fact that the language supports relative pointer comparisons for members of the same aggregate object, including structs. A pointer to a field declared "earlier" in the [flattened] sequence of fields  shall compare less than a pointer to a field declared "later".

Code: [Select]

int main(void)
{
  struct S { int a,b; } s;
  &s.a < &s.b; // <- this comparison is well-defined and shall evaluate to 1
}

From a very abstract point of view this can be satisfied through "compiler magic" even with reordering fields, but the practical reality says that this means that fields cannot be reordered.

[brucehoult]

Most don't realise that until recently it was impossible to write a threading library in C!

What changed?

You can *almost* write a threading library in pure and reasonably portable C using setjmp and longjmp (or sigsetjmp / siglongjmp).

The difficulty is that to create a new thread you need to change the stack pointer (and maybe PC) inside a jmp_buf but it's an opaque structure (different on every CPU type of course) so there is no standard safe reliable way to do that.

[james_s]

I quite like C as it is actually, but if there's one thing that comes to mind that I'd change, it would be to give it the ability to pass arrays to and from functions. Having learned Python first that is something that caused me some grief coding in C.

I thought that Python was intended to suppliment C for the reasons that the OP mentioned.

Python is primarily a scripting language, it's an interpreted language that is designed to be quick and easy to implement but it is not really suitable for embedded development. Yes there is Micropython but nobody is going to use that for serious embedded work.

[brucehoult]

I quite like C as it is actually, but if there's one thing that comes to mind that I'd change, it would be to give it the ability to pass arrays to and from functions. Having learned Python first that is something that caused me some grief coding in C.

I thought that Python was intended to suppliment C for the reasons that the OP mentioned.

Python is primarily a scripting language, it's an interpreted language that is designed to be quick and easy to implement but it is not really suitable for embedded development. Yes there is Micropython but nobody is going to use that for serious embedded work.

Not every "embedded" application requires microsecond or even millisecond performance. And many microcontrollers now have speed and capacity comparable to our desktop computers in the 80s.

As an aside, it amuses me when someone reviews a i3 or Atom computer and says "It's ok for light use but you wouldn't want to run Photoshop on it".

Dude. We used to run Photoshop on 33 MHz machines with 8 MB RAM and thought we were lucky.

[westfw]

I would be a lot happier with C if it had a decent native “string” data type and operations.
Although that would significantly increase the minimum size of the runtime footprint (which is currently close to zero…)

[DiTBho]

C + strings = php
Not good, but not too bad after a full training.

[bd139]

Not quite.

PHP = C + strings - pointers + crack smoking crazy.

[paf]

There are times when C is the right language, when Python is the right language, when PHP is the right language, when Assembly is the right language, etc...
But to use C (or any other language) in an effective manner, you need to know the "quirks" of the language and use it with the right set of tools.   
To use a nail you need a hammer, and to use a screw you need a screwdriver.

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".     

[tggzzz]

Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".   

The 1980s equivalent was "cc is half a compiler; the other half is lint"

[bd139]

To point out one flaw in paf’s comment: PHP is never the right language. That’s like using a marrow to hammer in nails. The nails keep winning. Apart from that I agree with the rest of the comment

[DiTBho]

Python is too slow for scripting on a Ath5 machine clocked at 180Mhz
Perl is good, but my productivity with Perl is very bad
Bash-scripting is a valid option, but dictionaries are not supported
(here is where I have to write C-modules to help bash, which means ... I have to hack the bash)
php already comes with string support, json dictionaries, and even networking capabilities

---> php looks the right tool for the job

[bd139]

Go is the right tool for the job there. It does all of those and farts out one compiles static linked binary. And isn’t PHP

[DiTBho]

Go is very good, but in my case is a bad choice because its main-implementation depends on llvm/Clang, which is hard to be cross-compiled for PowerPC, SH and MIPS.

It's mostly profiled for mainstream architectures, mostly x86 and Arm.

The Ath5 SoC has a mips32-r1-be core, when I tried to make Go running on it ... I found thousand problems that I don't frankly want to deal with because my purpose is not "to fix Go on mips", but rather making the ath5 to work for my applications.

[paf]

To point out one flaw in paf’s comment: PHP is never the right language. That’s like using a marrow to hammer in nails. The nails keep winning. Apart from that I agree with the rest of the comment

Thinking better, I agree with you...