Design a better "C"

[madires]

That's also an interesting idea, like some other suggestions mentioned before. However, it's more an issue of self-discipline to get things right instead of relying on a "smart" programming language or compiler.

[PlainName]

it's more an issue of self-discipline

I agree. It's why you find schematic symbols have pins that are all 'passive' rather than specifically inputs or outputs, and loop variables are almost guaranteed to be ints.

Code: [Select]

double plus1(unchecked double x)
On the one hand I think the current situation should be the default so it's compatible with existing code and practises. So the keyword would be 'checked' rather than 'unchecked'. But, as noted above, it requires a bit of discipline and would be left out by default more than it would be put in. So on the other hand having to explicitly decide it's unchecked would be better

[SiliconWizard]

That's also an interesting idea, like some other suggestions mentioned before. However, it's more an issue of self-discipline to get things right instead of relying on a "smart" programming language or compiler.

That's the almost eternal question when designing a new programming language. Now if discipline is all that was needed, we wouldn't need any coding rules, static analysis, code reviews, languages such as ADA. There would be no bugs, no security reports, no CWE. And so on.

Reasonable help from your tools is useful. No one is infallible. That's the whole idea behind almost any programming language that have been devised, actually. Except maybe... C. Ironically.
Sure there's a fine line between too little and too much. This is definitely hard. But at least taking hints from real-world issues that have been reported again and again is not unreasonable.

[SiliconWizard]

On the one hand I think the current situation should be the default so it's compatible with existing code and practises.

There is no requirement in this thread to come up with something that would be fully compatible with C. Otherwise, the better approach would probably be to try and get involved with the C std committee, and make proposals. The probability of being able to really make a change is pretty low though. C as a language has to keep the most complete backward compatibility possible. It's one of its strengths, but it does of course prevent a number of features to be added in order not to break existing code.

So the keyword would be 'checked' rather than 'unchecked'. But, as noted above, it requires a bit of discipline and would be left out by default more than it would be put in. So on the other hand having to explicitly decide it's unchecked would be better

The whole point of this kind of feature is to make it default. It's like making objects immutable by default in Rust. If the "more secure" approach is not default, then it's basically useless.

Error handling is related to this in that regard. I think there are definitely two categories of programming approaches out there.

The first one is to design for success. In this approach, it's considered that the normal execution flow is the one which is perfectly successful with no error or failure whatsoever. This has been coined the (in)famous "happy path". This is also the main idea behind traditional exceptions as a way of handling errors. Failure is considered exceptional; success it the normal path and is what should be favored.

The second one is to design for failure. Here, it's considered that failure will happen and that it's an integral part of "normal" execution. In this approach, you do careful error handling, you usually exclude exceptions (failure is definitely not considered an "exception"), and overall, error handling and input/parameter validation are an integral part of the code. They are considered every bit as important as the "happy path", and thus there is no reason to favor the latter and to try and "hide" error handling.

I'm more for the second one, and I wish the "happy path" concept would die a painful death.

[Siwastaja]

Wow, that's a great description of the two strategies.

Encouraging or even forcing people to use the second strategy would also have consequences of designing things that cannot fail in the first place to reduce the workload. But because the "happy path" mindset rules, designers often come up with totally unnecessary error paths "because they are not any extra work" "because no one bothers to really do anything with the errors anyway".

A good example are STM32 libraries where the functions return error codes, may time out, etc., and the examples check the return values (but don't do any proper failure logic, because that would be non-trivial). But if you look at the implementation more closely or read the manual, it becomes obvious the hardware cannot fail in such detectable way at all, unless of course the silicon is completely glitching, in which case different strategies (HW watchdogs, checking memory marker patterns...) are needed to improve reliability.

[PlainName]

STM32 libraries where the functions return error codes

A library may be designed for other hardware too, even hardware that doesn't yet exist. If there could be a failure mode which could also be handled in some way, the error should be returned even if it's impossible on that specific hardware. That's why it's a library and not example code (although with examples I'd allow even more rope on the basis that it should show the how without getting bogged down in detail).

[PlainName]

There is no requirement in this thread to come up with something that would be fully compatible with C.

OK.

[aandrew]

So for the small example:

Code: [Select]

int Something(int n)
{
int res;

if (n > 10)
res = 1;

return res;
}

I didn't want to believe you, especially since I get "uninitialized variable" warnings all the time in my embedded development, yet tested with gcc 4.7.2, arm-none-eabi-gcc 10.2.1 (20201103) and was shocked to find exactly what you said. Native GCC on the mac found it, but it's based on clang, so there you go.

TIL. Thank you.

[SiliconWizard]

So for the small example:

Code: [Select]

int Something(int n)
{
int res;

if (n > 10)
res = 1;

return res;
}

I didn't want to believe you, especially since I get "uninitialized variable" warnings all the time in my embedded development, yet tested with gcc 4.7.2, arm-none-eabi-gcc 10.2.1 (20201103) and was shocked to find exactly what you said. Native GCC on the mac found it, but it's based on clang, so there you go.

Yes, that looks unbelievable, right, given how simple this piece of code is? But yes, I think they have tamed the detection a lot in order to avoid false positives, to the point of not detecting obvious ones. That would probably warrant a bug report, if it hasn't been done already. I have issued a few of them already, so another one won't hurt.

Yep Clang does a good job. Try Cppcheck as well if you haven't already - it's pretty handy, and will detect a whole range of issues.

[SiliconWizard]

STM32 libraries where the functions return error codes

A library may be designed for other hardware too, even hardware that doesn't yet exist. If there could be a failure mode which could also be handled in some way, the error should be returned even if it's impossible on that specific hardware. That's why it's a library and not example code (although with examples I'd allow even more rope on the basis that it should show the how without getting bogged down in detail).

While I get Siwastaja's point of trying not to take error handling to a possibly useless extreme, I agree with you there. That makes interfaces more consistent, even if in some particular instances and implementations, it's useless.

I think we talked about this in STM32 HAL in another thread, and gave counter examples. For instance, some claimed that a time-out for a SPI master communication was useless, because it would usually mean the hardware was so borked that you may as well let the watchdog reset the whole thing. But, in SPI slave, if you're using a blocking call for transmitting data, a time-out could definitely occur! I also gave the example of I2C, even in master mode, that could time-out if the slave holds down the clock signal for some reason...

So, that gives a consistent interface for comm functions with a time-out parameter for all.

Now the fact most ST example code doesn't do anything useful with error codes from their own libraries doesn't mean that they are useless. It just means that ST devs are lazy, and that the examples are just meant to show basic functionality and are not meant as an example of good coding practices, nor as something you can directly re-use in production code.

[cfbsoftware]

Huh? If you use '=' for testing then you end up with one or two character tests. OTOH, use '==' and it's consistently two characters. And '==' is visually similar to, and differs in the right way, from '>='. Or '!=', etc.

I do not understand your line of thought. We have already 'ended up with one or two character tests':

Examples of two character tests are:

>= is 'greater than or equals'
<= is 'less than or equals'
!= is 'not equals'

Examples of single character tests are:

> is 'greater than'
< is 'less than'

The way my mind works would lead me to deduce that:

= is 'equals'

which then makes me wonder about:

== is 'equals or equals', whatever that means.

An alternative argument could be given that == would be more intuitive as an assignment operator as it is analogous to += and -=

[SiliconWizard]

Yeah as you said. Anyway. I think the ':=' assignment is simple and clear, and that the '=' sign for assignments is not so great. Wirthian languages win hands down here. But of course this is MHO.

Note that this is something that varies a lot depending on languages, sometimes to a useless degree of variation IMHO, but style is something so subjective anyway...

* '=' for assignment and '==' for equality are pretty common in C-inspired languages. ':=' is common in Wirthian languages, ADA and several others.
* Go uses both. '=' is the basic assignment, but ':=' is for declaring and assigning in a single statement.
* Zig does as in C.
* But ODIN (which is yet another C successor wannabe), which is not uninteresting, has additional weird "shortcuts" using the ':' character. You could have a look there: https://odin-lang.org/docs/overview/#assignment-statements

A lot of "creativity" for just assignment.

[cfbsoftware]

Yeah as you said. Anyway. I think the ':=' assignment is simple and clear, and that the '=' sign for assignments is wrong. Wirthian languages win hands down here.

I just checked the B language definition (C evolved from B). One of the examples includes this line:

if(a=n/b) /* assignment, not test for equality */

The presence of the comment is telling.

[brucehoult]

Yeah as you said. Anyway. I think the ':=' assignment is simple and clear, and that the '=' sign for assignments is wrong. Wirthian languages win hands down here.

I just checked the B language definition (C evolved from B). One of the examples includes this line:

if(a=n/b) /* assignment, not test for equality */

The presence of the comment is telling.

It tells that this is part-tutorial, intended for people coming from other languages?

[tggzzz]

Yeah as you said. Anyway. I think the ':=' assignment is simple and clear, and that the '=' sign for assignments is not so great. Wirthian languages win hands down here. But of course this is MHO.

I agree, but if you ever had to use an ASR33, you would understand a desire to minimise the characters typed

Algol also uses := for assignment, and predates B, of course.
Pukka Smalltalk uses a ← (left-pointing arrow) for assignment, but most bastardised modern Smalltalks use :=

[Just_another_Dave]

Yeah as you said. Anyway. I think the ':=' assignment is simple and clear, and that the '=' sign for assignments is not so great. Wirthian languages win hands down here. But of course this is MHO.

I agree, but if you ever had to use an ASR33, you would understand a desire to minimise the characters typed

Algol also uses := for assignment, and predates B, of course.
Pukka Smalltalk uses a ← (left-pointing arrow) for assignment, but most bastardised modern Smalltalks use :=

That reminds me to APL and R, although the second one uses <- instead to simplify its use as most keyboards don’t have a ← symbol

[nfmax]

I agree, but if you ever had to use an ASR33, you would understand a desire to minimise the characters typed

Which is why most Unix commands are short, and a significant proportion comprise alternating left hand and right hand characters

[tggzzz]

I agree, but if you ever had to use an ASR33, you would understand a desire to minimise the characters typed

Which is why most Unix commands are short, and a significant proportion comprise alternating left hand and right hand characters

Yes, but I haven't verified that left/right bias.

[DiTBho]

I don't know for what? but this morning a colleague mentioned she has to learn and use haxe 

[bd139]

They’re going to be loving that as much as my guys are loving Scala at the moment. Guaranteed. It’s so good we’re doing a rewrite in C# at the moment 

[SiliconWizard]

Yeah as you said. Anyway. I think the ':=' assignment is simple and clear, and that the '=' sign for assignments is not so great. Wirthian languages win hands down here. But of course this is MHO.

I agree, but if you ever had to use an ASR33, you would understand a desire to minimise the characters typed

Never have.
But sure, I understand that many of the syntax choices in the 60s and 70s were related to the limitations of the time, in particular in terms of keyboards and screen real estate. That's why they chose brackets in C instead of block-delimiting keywords. For the assignement, it assumes that assignments are more frequent in typical code than equality testing. Which is probably a reasonable assumption.

These days, hindering readability for those reasons doesn't make much sense anymore IMHO.

Algol also uses := for assignment, and predates B, of course.

Yes, it predated C and it ancestor B, which is why I mentioned that.

Pukka Smalltalk uses a ← (left-pointing arrow) for assignment, but most bastardised modern Smalltalks use :=

Oh, many languages at the time were using custom character sets. That of course caused major issues for interoperating with pure ASCII terminals.

[SiliconWizard]

I don't know for what? but this morning a colleague mentioned she has to learn and use haxe 

I've seen Haxe. The main point is that the compiler can apparently output code in many different languages, so that "portability" and interoperability on any given system/context should be much easier than any other language.

The language itself doesn't seem too bad, to be honest.
Problem, as always, is investing resources on a language that is not industry-standard. This is also why C is still that popular. Regardless of the merits, you know that time and resource invested developing in C won't be thrown away. If you're using Haxe, or whatever, for all you know, the next team may decide to trash it and the company will just have to cry for its losses.

Now one may argue that at least for those new languages that can generate source code in another, industry-standard language, you can always reuse the generated code itself. But experience as shown that automatically generated code was rarely neither very readable nor maintainable, so...

[bd139]

I write code generators occasionally. Yep.

That was sort of my point about Haxe earlier. Really in 90% of cases it’s better to build stuff in a language you can get any staff in.

[SiliconWizard]

That was sort of my point about Haxe earlier. Really in 90% of cases it’s better to build stuff in a language you can get any staff in.

Of course the choice of a language for a given context (project, team, company...) depends on factors outside of pure technical ones. Including, indeed, the availability of developers. This itself depends on the project and other constraints. In some settings, you may not mind having to train new people on a specific language or tool, it this has a definite added value for the project. In other cases, you may want people that are immediately productive.

This is a matter of benefits vs. cost ratio. The former approach has drawbacks, of course. It may not be a big problem during the initial development of a product, but for its maintenance, especially if there's some bug needing urgent fixing and most people that were good enough with the new language have left the company. OTOH, one possible benefit, from a staff POV, is that everyone having to use a new language they are not familiar with can avoid bad programming habits they may have cultivated over time.

[bd139]

The main issue on those sorts of decisions is staff turnover. You are basically pushing a training requirement on all new staff and adding a hiring and staff egress risk. I don’t know anyone who would willingly take a job at the moment to be trained in and write any language which isn’t one of the top N popular ones. Conversely people tend to leave if this is forced upon them.

This is one of my preferences around Go. There is a significant interest in it from a career development perspective.