Design a better "C"

[bd139]

Certain aboriginal people had that numbering system too.

[tggzzz]

Certain aboriginal people had that numbering system too.

The Australian aboriginies also have a different, fascinating perception of the world. To indicate where something is, they don't say "behind you" or "on your left", they say "north east of you" or "south".

[DiTBho]

counting scheme .. zero, one, many.

that's exactly how functional languages require to think 

zero -> empty list
one -> first element of the list
many -> remaining elements in the list

[bd139]

And C. Linked list struct containing pointer to next item and pointer to data  . And lisp to some degree with car cdr etc.

[SiliconWizard]

- Keywords are all uppercase, and the language is case-sensitive. Uppercase keywords really annoy me and my fingers. They were justified back in the days when text editors didn't have syntax highlighting, but these days, they are just a major annoyance IMHO.

This would have to be the most common gripe I have heard. To me it is like somebody saying they wouldn't drive a Ferrari because they can't get it in any colour other than red.

I'm sure it is, and I can see why. I don't quite agree it's just a simple matter of taste, although it's certainly partly this.
Again, I would fully understand how this would make the code a lot more readable in the absence of syntax highlighting. But otherwise, it's annoying. Even reading it is annoying (but OK, that part alone is a matter of taste I guess.) As to typing, sure you can implement tricks in text editors to make up for it, but I frankly hate editors that would "auto-correct" things while I type. It's extremely annoying, and I know many people agree. I never enable anything like this in my text editors. I never enable auto-completion on the fly either.  I hate things popping up when I'm typing. I set up a key shortcut for auto-completion when I need it. All this is absolutely not major of course. Just a little gripe. But the way a particular language appears on screen is important for readability IMO, and certainly we probably all have a different way of considering readability.

- Constants (CONST section) are typeless. They are essentially like macros. That bothers me. Not a huge dealbreaker, I admit, but I'd like typed constants. I know you can always declare variables, initialize them in the "body" of the module, and use them as constants, but they are not proper constants as they could be modified, at least within the module.

I'm not sure that I follow you here. Floating-point constants are REAL, string constants are character arrays, numeric constants are INTEGER. You can't assign a constant to a variable of a different type.

Maybe I didn't express it fully clearly. What you are talking about are *literals*. Every prog. language has a way of writing literals. But in CONST section, those are not linked to a type.
I guess the fact you don't see a difference is because of Oberon's simplicity which has only very few basic types (especially integers as I mentioned), no array literals, and so on, so that the type can always be unambiguously derived from the literal, but that's not always the case in languages for which there could be ambiguities.

- Related: you can declare variables and make them private to a module, but you can't make variables constant (AFAIR, please correct me if I'm wrong). So, I think that's a limitation.

Stand corrected Exported variables cannot be directly modified in a client module. There would need to be a 'setter' procedure also declared in the exporting module to enable modification. The setter procedure could then do any necessary validation if required.

Yes, but not within a module itself. I guess it all boils down to the point about CONST above. But I'll give you an example: since Oberon doesn't allow array or record literals, they can't be CONST. So you can't have a constant array or record within a module itself. It is a limitation IMO.

- Point I'm not 100% sure of: there are no array or record initializers. So initializing them is very clunky compared to other languages.

True. However, it is rarely a problem in practice for me as I rarely, if ever, use array or record initialisers even when using languages that allow them.

Many people do. It's much more compact that initializing members/items one by one with an assignment. C has solved the member "ambiguity" for structs since C99, you can pass the member identifier like: "{ .x = 1, .y = 2 }". It's compact and readable.

One somewhat related point is that to make up for it, developers in Oberon (and similar languages), following what Wirth was himself doing, tend to put several statements on the same line. So with the example above, they will usually just write: "S.x := 1; S.y :=  2;" and call it day. I for one have a rule of never putting more than one statement on a single line. I think it hinders readability, and that's something that for me makes a lot of Oberon code hard to read. Statements all over the place. Of course you're not forced to doing this. But I just don't like this style, and having no initializers for arrays and records will kind of push this style.

One way having no initiliazers ("literals") for arrays and records is a real issue regarding the point I made above with constants. You can't declare a constant array or record. Yes you pointed out that outside of a module, exported arrays or records will essentially act as constants, but not within the module itself. This can be problematic. You can argue that you may put all your "constants" in a separate module, and that would solve the issue. Which woud be fair enough, if making things a bit harder than needed.

I won't get into more details for dynamic allocation, but just saying the model is still limited for general-purpose use, and as we're talking about a replacement for C, there's not reason not to consider dynamic allocation. And, it seems that the ability to use a non-GC allocator in your implementation is an extension of Oberon. The report doesn't mention anything like this AFAIR.

- Something C was long plagued with as well: there are no fixed (and standard)-width integers. No unsigned integers in general either, except for the BYTE. So IIRC, you have BYTE (which should be an 8-bit unsigned integer on most platforms), and INTEGER, which is a signed integer. The width depends on the platform. If you need to define and/or access integers with a specific width, look elsewhere... you may have to resort to the SYSTEM module. Now see below as well.

An actual parameter declared as ARRAY OF BYTE can have ANY data type passed to it as long as it has the same size.

This is interesting, but not part of the original language report. You have acknolwedged it was lacking, and added this as an extension. Like your non-GC allocator. I'm sure you have added a few other extensions as well, for instance for dealing with interrupts. So, see, you were forced acknowledging some things were lacking in the language. Now all things I've mentioned here would likely be pretty simple to add/modify in the language as well. It would just not be the exact language defined in the report...

As to integers, I still think there are things missing. Not having integers of various widths makes certain kinds of arithmetics difficult or clunky. Having only BYTE and INTEGER doesn't quite cut it IMO. Not that you can't circumvent this, but it's a bit limiting.

Not at all. Thank you for your feedback. I very much appreciate the time and thought you have put into it.

Well, this is a thread about thinking of a replacement for C, and I mentioned Oberon while saying it wasn't quite there, so obviously that meant I thought there were things missing. Still, I suggest anyone at least curious to have a look at Oberon.

Oh, and as said here, you have already implemented a number of extensions. Possibly adding a couple others would make it even better. That was my point.

Now apart from the few things I talked about, and that could be seen as "details", there's something more drastic.
Some people (many these days actually) do think modern programming languages should include built-in constructs for dealing with "parallel multitasking" (multi-threading if you will), some of those people are in this thread. But Wirth was convinced of the opposite. C is obviously lacking anything regarding this, but that's part of what many people think it's seriously limited. So if you're one of those people, you would have to consider this for any potential language replacement.

[DiTBho]

C is obviously lacking anything regarding this, but that's part of what many people think it's seriously limited. So if you're one of those people, you would have to consider this for any potential language replacement.

If you need a practical target of reference, look at the Epiphany-V, for instance the version with 1024-cores.
Programming it in C has already demonstrated to be limited and very prone to catastrophic results 

[brucehoult]

One way having no initiliazers ("literals") for arrays and records is a real issue regarding the point I made above with constants. You can't declare a constant array or record. Yes you pointed out that outside of a module, exported arrays or records will essentially act as constants, but not within the module itself. This can be problematic. You can argue that you may put all your "constants" in a separate module, and that would solve the issue. Which woud be fair enough, if making things a bit harder than needed.

This is an obvious problem in embedded, as you'd have no way to get initialised constant data structures into ROM. They'll need to be stored in RAM, and set up at program startup by code in ROM -- code that is several times bigger than the data they're initialising.

[SiliconWizard]

One way having no initiliazers ("literals") for arrays and records is a real issue regarding the point I made above with constants. You can't declare a constant array or record. Yes you pointed out that outside of a module, exported arrays or records will essentially act as constants, but not within the module itself. This can be problematic. You can argue that you may put all your "constants" in a separate module, and that would solve the issue. Which woud be fair enough, if making things a bit harder than needed.

This is an obvious problem in embedded, as you'd have no way to get initialised constant data structures into ROM. They'll need to be stored in RAM, and set up at program startup by code in ROM -- code that is several times bigger than the data they're initialising.

That too. Now I'll wait for cfbsoftware's reply on that; they may have added specific extensions/behavior to their compilers to allow doing exactly this - maybe at the link step.

In Oberon, modules have a "body" in which you can typically put code for initializing them - which would be where you'd put the code for initializing constant arrays and records for instance. I guess the compiler/linker can relatively easily detect which variables are only set in the module body and never modified outside of that, and then automatically put them in an appropriate section of memory. I'm curious to know if this is what cfbsoftware have implemented.

But in any case, the language itself - at least without extensions - cannot directly describe variables that are indeed constants. So I'm saying this can be usually inferred, but not directly expressed by the developer.

[DiTBho]

I saw a C-like compiler made by a Japanese company that adds three new keywords: in, out, inout
When you write a function, you can use one of these keyword to describe if the variable is

• something that can only be read, therefore a constant (in)
• something that can only be written out as result (out)
• something to be read in and modified back (inout)

Anyway, this only tells the function how to behave with parameters, but i do find it clear and elegant.

It would be cool if in, out, inout could be used in a typedef

Code: [Select]

typedef long in const_uint32_t;
typedef long inout uint32_t;
typedef char in const_char_t;

const_char_t msg[]="hello world, I am actually a true constant, nobody can touch me";

This way it could also be super easy to write a linkerscript that allocate all the "in" variables to the constant pool section.

[gf]

This way it could also be super easy to write a linkerscript that allocate all the "in" variables to the constant pool section.

I don't see the point. If you define

    const char msg[]="hello world, I am actually a true constant, nobody can touch me";

then (by default) msg is placed in the .rodata section anyway (which is baisically the constant pool). No proprietary annotation is required for that.

[brucehoult]

I saw a C-like compiler made by a Japanese company that adds three new keywords: in, out, inout
When you write a function, you can use one of these keyword to describe if the variable is

• something that can only be read, therefore a constant (in)
• something that can only be written out as result (out)
• something to be read in and modified back (inout)

Anyway, this only tells the function how to behave with parameters, but i do find it clear and elegant.

Ada did exactly this, 40 years ago.

[DiTBho]

Ada did exactly this, 40 years ago.

As well as an architecture analysis and design tool does to design projects 

When engineers design and plan a project with AADL/Hood, both C and Ada projects are defined in the same way regarding their interfaces, thus I guess for the Japanese company I visited in 2014 it was a "natural" choice, since they use these tools on regular basis.

[tggzzz]

I saw a C-like compiler made by a Japanese company that adds three new keywords: in, out, inout
When you write a function, you can use one of these keyword to describe if the variable is

• something that can only be read, therefore a constant (in)
• something that can only be written out as result (out)
• something to be read in and modified back (inout)

Anyway, this only tells the function how to behave with parameters, but i do find it clear and elegant.

Ada did exactly this, 40 years ago.

It isn't far off being a truism that academic papers on C/C++ rarely cite other languages, whereas academic papers on other languages refer to many languages. Several conclusions could be drawn, none particularly flattering to the C/C++ community.

[DiTBho]

I don't see the point

It's more clear to read and coherent if also applied to function parameters as well as global constants.
It allows to specify write-only registers, and as bonus, it's also directly compatible with AADL/Hood tools.

[gf]

I meant, already now (w/o introducing in, out, inout) you can write a linkerscript that allocates all constant variables in a constant pool section.

Subjectively, I find the terms in, out, inout intuitive for function parameters, but not so intuitive for global variables. You are obviously used to AADL/Hood tools, while I and possibly other are not. But at the end the name of the keyword is just a matter of definition, of course.

Currently there is indeed no way to define write-only variables in C. But a regular variable which is only written, but never read, is virtually useless. Why should a variable be written, if its value is ignored anyway? Eventually it would only make sense in conjunction with C extensions which map C variables directly to hardware registers of peripherals. Or as type qualifier (analog to const and volatile), in order that e.g. lvalue expressions referring to peripheral registers could be tagged write-only.

[DiTBho]

Currently there is indeed no way to define write-only variables in C. But a regular variable which is only written, but never read, is virtually useless. Why should a variable be written, if its value is ignored anyway?

The ICEs we use have some memory mapped registers, for instance the debug_console_out is a write only memory mapped register, as well as a lot of peripherals made by Motorola and Freescale.

If you try to read from those registers, the manual say the hardware behavior is not guaranteed, but practically the ICE goes mad and you have to force an hardware reset.

And it's the point when you hammer your head on the wall: oh, see, the code has been compiles correctly, just ...  d'oh, at line-x I forgot it was a write-only register. ---> face palm and embarrass

This info is also exported to the ICE itself, so if you don't tell it to not read at location x, soon or later it will, unless you spend time to manually edit the symbol list, or post process them with sed, both procedures which somehow work, but they prone to consume time and introduce errors.

The WDT of the 683xx as well as the WDT of the PCE500 is like that. Don't try to read from any write-only register, or hell will look into you.

[paf]

This way it could also be super easy to write a linkerscript that allocate all the "in" variables to the constant pool section.

I don't see the point. If you define

    const char msg[]="hello world, I am actually a true constant, nobody can touch me";

then (by default) msg is placed in the .rodata section anyway (which is baisically the constant pool). No proprietary annotation is required for that.

If you only want a string constant, this will do:

    char * msg="hello world, I am actually a true constant, nobody can touch me";

[TheCalligrapher]

I don't see the point. If you define

    const char msg[]="hello world, I am actually a true constant, nobody can touch me";

then (by default) msg is placed in the .rodata section anyway (which is baisically the constant pool). No proprietary annotation is required for that.

Um... Formally/pedantically it is not entirely accurate.

What you have on the right-hand side is a string literal. It is a non-modifiable nameless object of array type (which can and will be normally placed in .rodata, yes). BTW, in C it is a `char [N]` array, not a `const char [N]` array: even though it is non-modifiable, its type is not const-qualified that way. Just a C-specific historical oddity.

What you have on the left-hand side is an ordinary named const-qualified array `msg`, which is (can be) located in "regular" memory. That array `msg` is initialized by the string literal by copying data from the string literal to the array.

In other words, conceptually you have two separate objects here, not one: a string literal and an array `msg` holding its copy.

The rest is work of an optimizer in a real-life implementation. The optimizer correctly concludes that there's no need for two separate objects in this case and just one is enough: instead of copying the string literal iinto `msg` the compiler simply "maps" `msg` directly onto the string literal (in .rodata).

---

If one'd want to avoid the need for this conceptual transformation, one'd used the following instead

    const char *const msg = "hello world, I am actually a true constant, nobody can touch me";

[gf]

The ICEs we use have some memory mapped registers, for instance the debug_console_out is a write only memory mapped register,...

I mean, for "regular" program variables (in RAM, only accessed by the CPU, and not shared with any peripherals) it is virtually useless.
I did not deny the usefulness for memory mapped registers of peripherals, which are indeed write-only sometimes.

An alternative (in order to prevent accidental read access) were of course, to hide the definition of the debug_console_out register from all modules of the program, and to provide an accessor function, (say) write_debug_console_out(....) which needs to be called. Then only the write_debug_console_out() function needs to take care.

If you only want a string constant, this will do:

    char * msg="hello world, I am actually a true constant, nobody can touch me";

But msg is not an array variable then, but a pointer, and msg is not a constant variable either.
And letting a char* variable point to a string literal (which has type const char*) is not clean either (though usually still accepted by C compilers).
A "clean" definition of a constant pointer to a constant string were rather:

Code: [Select]

const char * const msg = "hello world, I am actually a true constant, nobody can touch me";

[SiliconWizard]

I saw a C-like compiler made by a Japanese company that adds three new keywords: in, out, inout
When you write a function, you can use one of these keyword to describe if the variable is

• something that can only be read, therefore a constant (in)
• something that can only be written out as result (out)
• something to be read in and modified back (inout)

Anyway, this only tells the function how to behave with parameters, but i do find it clear and elegant.

Ada did exactly this, 40 years ago.

That's also something you can find in Component Pascal IIRC (and, I think the earlier Modula-2 and -3).

As I said earlier in the thread, actually Ada has pretty much everything most people have asked for in this thread. If again there were a lighter language based off Ada and with much relaxed runtime requirements, I would go for it in an instant.

I've seen Nim, inspired by Ada (and related languages), which didn't look too shabby. https://nim-lang.org/
They unfortunately had the very bad taste of picking a syntax à-la Python. That's enough to instantly trash it.
Also, I don't know how fit it would be for embedded development, haven't looked closely enough.

[PlainName]

They unfortunately had the very bad taste of picking a syntax à-la Python.

And in the 'get to know it' documentation provide an excellent example of the issue, perhaps unwittingly:

Code: [Select]

while guess != number:
  raw_guess = readLine(stdin)
  if raw_guess == "": continue # Skip this iteration
  guess = str.parseInt(raw_guess)
  if guess == 1001:
    echo("AAAAAAGGG!")
    break
  elif guess > number:
    echo("Nope. Too high.")
  elif guess < number:
    echo(guess, " is too low")
  else:
    echo("Yeeeeeehaw!")

[SiliconWizard]

And letting a char* variable point to a string literal (which has type const char*) is not clean either (though usually still accepted by C compilers).

It's even worse than just being "accepted". It will yield no warning, neither with GCC nor with Clang, even with -Wall and even with adding -pedantic.
But there is worse.

Code: [Select]

void Test(void)
{
   char * msg="hello world, I am actually a true constant, nobody can touch me";
   *msg = '\0';
}

Yes, GCC will accept this without a single warning. Not just that; it will actually put the string literal in the .rodata section, where indeed it's meant to belong...
And the generated code actually writes a zero to the first byte.

Of course this piece of code sucks and a competent programmer will avoid something like this. But still, this could happen in more subtle cases and that's where static analysis tools can be handy.
For instance, cppcheck on this piece of code yields:

Code: [Select]

Test4.c:3:15: error: Modifying string literal "hello world, I a.." directly or indirectly is undefined behaviour. [stringLiteralWrite]
   char * msg="hello world, I am actually a true constant, nobody can touch me";
              ^
Test4.c:4:5: note: Modifying string literal "hello world, I a.." directly or indirectly is undefined behaviour.
   *msg = '\0';

Note that this is one of C's oddities - where "undefined behavior" sucks. This is a case of UB, so most compilers will just shut up and let you shoot yourself with an UB.

OTOH, if you write:

Code: [Select]

void Test(void)
{
   const char * msg="hello world, I am actually a true constant, nobody can touch me";
   char * msg2 = msg;

}

You'll get a proper warning for the second assignment. Because this case is not UB. You like this already?

A "clean" definition of a constant pointer to a constant string were rather:

Code: [Select]

const char * const msg = "hello world, I am actually a true constant, nobody can touch me";

Yes, as TheCalligrapher said above.

[DiTBho]

If again there were a lighter language based off Ada and with much relaxed runtime requirements, I would go for it in an instant.

Yup, I know what you mean, 15 years ago I tried to develop a ada crosscompiler for hc11; it worked on the top of gcc-v3.4.*, but I had to relax  the run-time requirements and as result .. it was just Ada-sugar.

Better than nothing, but practically ... a toy. Sorry 

[TheCalligrapher]

But msg is not an array variable then, but a pointer, and msg is not a constant variable either.

True.

Although you can also do this:

Code: [Select]

char (*const msg)[12] = &"Hello World";

This `msg` is rather unwieldy in subsequent use, but it does declare a "pointer to an array", which preserves the "arrayness" of the pointed object.

And, unfortunately, const-correctness rules of C will not allow you to declare it as `const char (*const msg)[12]` (another historical oddity).

And letting a char* variable point to a string literal (which has type const char*) is not clean either (though usually still accepted by C compilers).

That is incorrect. As I already stated above, a string literal in C has type `char [N]`. Firstly, it is not a pointer, it is an array. Secondly, it is not qualified by `const`. (In C++ it would be, but not in C.)

So, the result of array-to-ponter decay applied to a string literal in C is `char *`, not `const char *`. It is not something "usually" accepted by C compilers, it is a hard rule of the language.

[tszaboo]

;, **,  print("%20.5s\n", str);, callbackpointers, cmsis, vendor libraries, returning more than 1 parameter, atoi, pointerstopointers, side effects, asshats who intentionally program their code for side effects, unsafe typecasting, no (a,b) = (b,a), accessing data in a struct which is passed as a pointer, operator precedence, goto, if(a=b) is always true with no warning, calling int as int32_t to be able to port some code into a 8051 (just in case), and so on.
I hate C. I don't want to code C anymore ever in my life.
Just no. You don't have enough money to make me do it.