[GregBuchholz]

* Eliminate sources of undefined behavior * Remove implicit type casting * Have a way to check the hardware overflow flag from the language * Saner syntax for declaring variables (i.e. function pointers) * get rid of null-terminated strings * a module system instead of the preprocessor

[pjmlp]

Additionally:

- Proper arrays with bound checking, which can locally be turned off, if required for performance reasons

- Explicit operation for converting arrays into pointers

[nwmcsween]

-fstack-protector && -D_FORTIFY_SOURCE=2

[pjmlp]

Where is that defined in the C standard?

Because you see, if it is compiler specific, it is not part of the language.

[RodgerTheGreat]

Also:

- remove crufty alternate syntaxes such as trigraphs and K&R-style definitions

- a multiple-pass compiler which removes the need for explicit prototypes/header files

[pornel]

• Modules are on the way: http://clang.llvm.org/docs/Modules.html

• Check for overflow would be awesome indeed.

• Undefined behavior avoids massive performance penalties on hardware that wouldn't match the defined behavior, so it's a feature and unlikely to go away (compilers may warn you though).

[pjmlp]

> Modules are on the way: http://clang.llvm.org/docs/Modules.html

Yeah, with luck they will be part of C++17, you just need to wait 4 years for them to be defined and then around 5 more for all major compilers, across all OS to support them.

They are not even being discussed for the next C standard, and thus similarly to C blocks, it will remain a clang language extension.

[nwmcsween]

1. Undefined behavior is because not all hardware is the same

2. Pedantic but it's nul terminated, null is something either the same or completely different depending on the implementation. Also what would you recommend for non null strings? passing a struct around of *s and size_t len, _that_ is a horrid idea.