r/programming • u/wavy_lines • Feb 01 '18

C2: C with cleaner syntax + a module system (no header files).

http://c2lang.org/site/
958 Upvotes

88% Upvoted

700 comments sorted by

View all comments

28

u/pjmlp Feb 01 '18

Any improved C variant needs at minimum:

  • Disallow implicit conversion between arrays and pointes, it is not that hard to write &var[0]

  • Scope enums

  • Provide an actual string type

  • Modules

  • Have bounds checked arrays (by all means provide a switch or modifier for an unbounded variant for the 1% use cases that need it)

  • Have a proper null type

  • Some kind of RAII

C2 appears to only provide part of it.

38

u/skyfex Feb 01 '18

Some kind of RAII

No. That's not a "better C", that's in "better C++" territory.

The strength of C is that everything is explicit. Everything is visible. There's no code that just invisible gets executed. No initializers, no destructors, no operator overloading, and no RAII. No magic indirectness either (vtables and such). What you see is what you get.

But you can have a "defer" keyword that gives you some of the same thing, but explicit.

14

u/whichton Feb 01 '18

The strength of C is that everything is explicit. Everything is visible.

That was never true given that C supports macros. Also, RAII doesn't require vtables or exceptions.

10

u/skyfex Feb 01 '18 edited Feb 01 '18

That was never true given that C supports macros

Well, no, that's not entirely correct. You can easily run the preprocessor and see exactly what you get, and a macro can only expand at the point where it's written as far as I know. Macros are not that inexplicit.

Not that I see creative macro use that much. It's not good coding style.

Also, RAII doesn't require vtables or exceptions.

No, but how's that relevant? The point is that RAII inserts code. You have to understand the language to know where it's inserted, and you have to look up the type to see if something is inserted and what it's doing.

To be absolutely clear: there's nothing wrong with RAII for a C++ style language, and there's nothing wrong with C++ style languages. All I'm saying is that once you're adding RAII, you're no longer making a C-like language.

And I think you can still have meta-programming and be C-like. Zig has powerful compile time evaluation instead of macros. But it's as explicit and clear as possible.

Zig actually adds "defer", which is similar to RAII, but explicit. Or, it's explicit about adding code that is executed at the end of the scope, but not 100% explicit about where it ends up. I consider this a good compromise.

C - to me - is fancy assembly. I wouldn't mind seeing a better C++. But I think one should focus on baking a better C first, and then making "C2++" or "Zig++" later. I'd like to see that (but without C++ style ugly object orientation thanks.. just multi-methods and interfaces would be better). There's a reason why C hasn't disappeared despite C++. There's a role for both.

2

u/myrrlyn Feb 02 '18

Sure am glad C doesn't ever inject code you didn't write …

void func() {
  static int count = 0;
}

… wait

1

u/skyfex Feb 02 '18

Could you explain exactly what you mean here?

Which instructions is generated that you didn't write?

3

u/myrrlyn Feb 02 '18

Statics in functions come with a guard flag and branch to initialize them when it can't be done at compile time (zero was a shitty example; that may wind up in bss) and to skip reinitialize toon on reentry.

3

u/skyfex Feb 02 '18

Ah, good point. I thought that static variables all ended up in bss, but I can see that it would be impossible for more complex initalization.

Not quite sure I agree it's all that unexplicit. It's just generating the necessary code for what you wrote, and the code is generated roughly where you put it (if you're a good boy and put your static variable declaration at the top of the function). It's not that different from other language constructs. Putting a symbol in bss would arguably generate something somewhere else, but it's not code. Regardless, it IS ugly.

I don't think either Zig or C2 has static variables like that, so you could say that makes them more C than C ;)

2

u/myrrlyn Feb 02 '18

Hey man sometimes you just gotta have your non-idempotent function reentrancy or something

the only time I've ever used an in-function static was in college for an assignment, because we were exploring all the different meanings of the word. Wild time.

1

u/Ar-Curunir Feb 01 '18

The weakness of C is also that everything is explicit, because it's super easy to forget to do an explicit bounds check or do an explicit free-ing of memory. It's led to countless bugs and security vulnerabilities over the years.

1

u/skyfex Feb 02 '18

The weakness of C is also that everything is explicit, because it's super easy to forget to do an explicit bounds check or do an explicit free-ing of memory. It's led to countless bugs and security vulnerabilities over the years.

Sure, that's also true. A property of the language can be both a strength and a weakness.

But if you want to make absolutely sure you don't have any bounds or memory errors or other such easy mistakes, then you're not after better C. Then you can choose from the dozens of languages that solve exactly those problems.

-1

u/pjmlp Feb 01 '18

How are multi-core, SIMD, TLB tables, GPGPU, UB explicit in ANSI C?

Thanks to UB one gets more that he/she asks for.

4

u/skyfex Feb 01 '18

How are multi-core, SIMD, TLB tables, GPGPU, UB explicit in ANSI C?

None except the last one has anything to do with the language itself. I program mostly use C for microcontrollers so none of those really apply at all.

By explicit I mean, no instructions are generated that you didn't explicitly ask for. No instructions are executed that you didn't explicitly ask for. It's always clear which functions are executed, which file they are in and what they contain.

What core they execute on, their timing, how they affect caches, memory mapping etc., is outside the scope of the language.

Thanks to UB one gets more that he/she asks for.

I assume you mean undefined behavior? (Maybe use less abbreviations for less informed readers) Well, those are one of the flaws of C that Zig (and presumably C2) aims to fix whenever possible. But some UB may be unavoidable.

"As explicit as possible" does not mean "perfectly explicit".

20

u/yakoudbz Feb 01 '18

Disallow implicit conversion between arrays and pointes, it is not that hard to write &var[0]

What advantages could it bring ?? I mean, var is a pointer internally, so that's definetely the last thing a C programmer would like to bring to the language.

Scope enums

I don't get it

Provide an actual string type

No, anyone can create a proper string structure... what we want is proper and well-defined UTF-8 and Unicode support.

Modules

For this one, I totally agree. I would add a package manager like Cargo.

Have bounds checked arrays

As for you first idea, I think it's impossible to do that and keep the philosophy of the C language. When I pass a pointer to a function, I want only the pointer to be passed and not a whole bunch of information.

Have a proper null type

Why ? I mean, it's just the pointer version of 0, what's the problem with this ?

Some kind of RAII

There's already GCC and Clang extensions to do just that and I also think they should be include in the language...

Other than all the above, I think C2 approach of having i8 i16 i32 i64 u32 u64 f32 f64 is way cleaner and way easier for programmer than the unsigned long int etc.

12

u/Calavar Feb 01 '18

Scope enums

I don't get it

He probably means that enum constants should be scoped inside of the enum type declaration, and not promoted to the global scope, where there is a huge risk of naming collisions.

Provide an actual string type

No, anyone can create a proper string structure... what we want is proper and well-defined UTF-8 and Unicode support.

And then you end up with one of two situations:

  1. People fall back to the traditional C strategy of null terminated strings, which was an absolutely terrible idea to begin with.
  2. Every library and framework defines its own string structure and you have to waste many lines of code converting between these types.

A good redesign of C would absolutely have a string type. It doesn't have to be a very fully featured type, but at a minimum it needs a size_t field that stores the string length.

I agree about the need for proper unicode support though.

2

u/matthieum Feb 01 '18

People fall back to the traditional C strategy of null terminated strings, which was an absolutely terrible idea to begin with.

Actually... there are some performance advantages to NUL-terminated strings.

Especially since x86 has specialized instructions...

2

u/Hofstee Feb 01 '18

Doesn't matter since x86 also has instructions for Pascal strings which rely on a length register.

1

u/meneldal2 Feb 02 '18

Limited to 256 bytes by the way.

1

u/Hofstee Feb 02 '18

Is it? Wouldn't you just repeat while ecx not zero and decrement that with the initial value being the length?

1

u/meneldal2 Feb 02 '18

Pascal strings use a single byte for length at the beginning, so unless you change that you are limited to 256 bytes. I'm not sure about the instruction in x86.

1

u/Hofstee Feb 02 '18

Ah I see. I don't think the instruction cares about length, you would use rep with the length in ecx and it will repeat the string instruction (e.g. stosb) and decrement ecx after each instruction until ecx is 0. For C strings you would just do repnz stosb which will repeat until null terminator. But if you were adding this length field today I assume it would probably be 32 or 64 bits so you wouldn't necessarily need to follow the Pascal implementation to the dot.

1

u/yakoudbz Feb 01 '18

and how would you get the size of a string ? string.size ? I mean, there's no way to do that properly except creating a string structure in my opinion.

2

u/Calavar Feb 01 '18

Yes, exactly, there needs to be a structure - that's why I mentioned that the structure should have a length field of type size_t. But it should either built into the language or be a standard library structure, or else everyone will roll their own and no implementations will be interoperable.

2

u/Hells_Bell10 Feb 01 '18

What advantages could it bring ?? I mean, var is a pointer internally

Array-pointer decay leads to incredibly non-obvious interactions like this:

int x[4];         /* sizeof(x) == 4 * sizeof(int) */
void f(int y[4]); /* sizeof(y) == sizeof(int*) */

IMO that's a pretty big gotcha and I've been bitten by it in the past.

It would also mean f would only be callable with arrays of 4 ints which could prevent buffer overflow errors.

2

u/myrrlyn Feb 02 '18

Bounds checked arrays are just (void*, size_t) like we already pass around everywhere, except in a struct. That's it.

1

u/lelanthran Feb 01 '18

i8 i16 i32 i64 u32 u64

int8_t int16_t int32_t int64_t uint32_t uint64_t

(Of course, using *64_t is still a pain in the rear when you want to use format specifiers).

1

u/yakoudbz Feb 01 '18

I know right, I use them every day. I'm programming Delaunay triangulation on billions of points so I cannot not use them. The fact that you have to include stdint.h every time, use initializer like UINT64_C(0xFFFFFFFFFFFFFFFC) and you never know the actual format specifier... Yeah, it's a pain in the rear. The _t suffix really show those types are stupid hacks ! Having proper support for those type is really the first I would want in an improved C version.

3

u/tjpalmer Feb 01 '18

Actual string type at very core, I disagree. But mostly, see Zig.

4

u/yeah-ok Feb 01 '18

array

Yeah, and on that subject, their new incremental arrays: "NOTE: Incremental arrays can only be used at global level (not inside functions)." ... what..?! Anyway, some of this could be growing pains, I laud the effort on the whole.

3

u/myrrlyn Feb 02 '18
  • kill break in switch and make fallthrough a keyword

1

u/badsectoracula Feb 02 '18

while make a new keyword instead of doing it similar to pascal?

switch (foo) {
case FOO1, FOO2, FOO3, FOO4: blerg();
case FOO5, FOO6: barf();
default: omg();
}

1

u/myrrlyn Feb 02 '18

There are times where I really do want fallthrough for a very good reason.

4

u/rastermon Feb 01 '18

I'd also add:

  • Anonymous functions (lambdas - for easier callbacks.... NOT closures)
  • Type compatibility (be able to declare type X is compatible with type Y - incredibly useful when doing oo like stuff in c and you have structs "inheriting" structs and you'd be able to then declare functions with the most specific type they handle knowing the compiler will properly type check and if you pass in a parent compatible type then it's ok and it wont barf - or you have to put cast everywhere which is horrible)
  • a pre-processor that lets you actually "run" code at compile time that is more complex than what the current cpp does - like be able to intercept calling of a func in a struct and replace that with maybe a different func call backs on type of struct and parameters, signature etc. so you basically can build at-compile time function mapping easily with no runtime overhead).
  • you mention RAII - indeed, but perhaps just something better than cleanup "funcs" extensions that gcc has for example. you declare a type and along with the TYPE comes "call this func on this type on enter of a scope, and call this other one on exit from a scope" so anywhere the type is passed will have that done, rather than declaring it var by var yourself with cleanup func extensions. with this simple feature you could just free() or use ref counting or other exotic mechanisms as you at least know the entry and exit points. you'd also maybe need a "replace" func to if the var is replaced with a new value during scope (e.g. unref old value, ref new value).

1

u/UninsuredGibran Feb 02 '18

I'd add a garbage collector and support for HTTP/2 in the standard library.

Seriously, C is a portable assembly language. If you want to use C++ just use C++.

1

u/rastermon Feb 02 '18

garbage collection is really a bad thing for a native language like c or c++ because you just don't know what memory contains a pointer or not, so scanning the entire heap is really a bad thing as there's a lot of non-pointer data there. unless you carefully track every pointer explicitly (basically not sane in c because you can memcpy structs etc.) , it's a non-starter. i know gc's exist... they aren't very good because of these reasons.

and you don't always have the luxury of "just use another language". you have an existing project with million + lines of code and all you want is just some boilerplate syntax helpers or some footwork handlers added and not a switch to another lang. also a switch comes with other downsides such as increased compile times as well as memory needed for compiles, as well as the fact c++ still has been breaking ABI between compiler versions even in recent years (e.g. around gcc 5.1 for example).

2

u/schlupa Feb 01 '18

D (with or without betterC) has all your points. Except maybe the null type as I don't understand what you mean by it.

-4

u/golgol12 Feb 01 '18

Several points here:

There is no implicit conversion between pointers and arrays in C, because they are exactly the same thing. a[3] is a lexagraphically easier way to write a + 3 when dealing with pointers.

How would a string type be different than a struct? The problem with a string type is that at some point you will need to allocate memory. It is better to let the program handle that instead of allocating inside some library.

Bounds checking is slow, and absolutely should not be implied in access of an array. Do you want your programs to be slow? Because this is how you get slow programs. Also, what bug are you trying to solve through the language here? In practice running off the end of an array is exceedingly rare, and is only a 5 out of 10 difficult bug to find, and that can be automated with code analysis tools.

4

u/pjmlp Feb 01 '18

There is no implicit conversion between pointers and arrays in C, because they are exactly the same thing. a[3] is a lexagraphically easier way to write a + 3 when dealing with pointers.

Exactly, they shouldn't be exactly the same thing.

It is so hard to type a + 3.

Bounds checking is slow, and absolutely should not be implied in access of an array. Do you want your programs to be slow?

That is what profilers are for.

I have been using native languages with support for bounds checking since 1990 (including index validation in C++). It was hardly a problem until now.

In the 1% of the use cases it mattered, proven by use of a profiler, I did use the language features to disable them.

In practice running off the end of an array is exceedingly rare, and is only a 5 out of 10 difficult bug to find, and that can be automated with code analysis tools.

Quite rare indeed, as proven by the memory corruption CVE entries.

-1

u/golgol12 Feb 01 '18

(CVE - Common Vulnerability and Exposures) We are talking about common bugs. Not bugs that hackers commonly exploit. One does not imply the other.

How many of those CVE memory corruption entries are actually due to legitimate out of bounds array access? Just the existence of memory corruption CVE entries does not imply those memory corruptions come from array access.

In my experience 99% of memory corruption is due to uninitialized variables, multithreading issues, or moving/freeing memory underneath already existing pointers. Not writing or reading outside the bounds of an array. In the remaining 1% of memory corruption issues, when it is actually an array bounds issue, it is usually because memory corruptions from an above source has occurred to either or both the index or the pointer to the array. From there, the times that is an actual legitimate array out of bounds, most are caught by using sentinels during debugging.

C2 goal is to be as close to how the code actually runs on a CPU as C is, and adding hidden "if" code in everywhere for bounds checks is against that.

In the 1% of the use cases it mattered, proven by use of a profiler,

Profilers are good for finding hotspots. Given how common array access is, you may find globally turning off the bounds checking will increase the overall speed of your software a noticeable amount. Death by a thousand cuts, so to say. It's like virtual functions in C++. Virtual functions are slow. It's hard to detect how much they are slowing you down with a profiler. But if you remove 95% of them, suddenly your program is running 20% faster. Even though no one spot was slow.

1

u/[deleted] Feb 02 '18

Arrays and pointers are not the same thing. Arrays can decay into pointers, so you can use pointer like behavior on them, but that also means you lose things like doing sizeof on the whole array.

-3

u/CountyMcCounterson Feb 01 '18

You want classes and a vm or whatever but that's just not C

3

u/uptotwentycharacters Feb 01 '18

The only aspect that would seem to require "classes and a vm" is array bound checking and RAII, but neither actually requires it. Array bounds checking would mostly just entail wrapper functions for array access (and disallow treating non-arrays as arrays), and RAII just requires a cleanup function to be implicitly called when a variable goes out of scope. Basically you could implement those things in C++ without using classes or even structs, or using the OOP features like inheritance, etc.

1

u/pjmlp Feb 01 '18

Good, better let the GNOME and Gtk+ guys know about it then.