That would allow cleanup and other such actions without resorting to such hacks as: "goto cleanup" pattern, separate functions, fake for loop to break out of, ...

It would be nice to have this be a part of the standard.

Edit: Ah, I see; you're more worried about them turning C into the next C++ :) I might even agree some days.

What they don't share is mindset; C is all about keeping it simple, I don't even know what C++ is about any more, but it sure isn't simple. Many fundamental tricks that are routinely pulled in C require jumping through plenty of hoops to keep a modern C++ compiler happy.

Speaking of interop, calling into C from other languages is very different from calling into C++. Yes, you can write C wrappers, but it's rarely done. And the further the language drifts into template lala land, the more tricky it gets.

Not in my experience. Currently my man open source project consists of some 70,000 of C which compiles as C++. Maintaining C++ compatibility takes very little effort. I tend to switch to C++ before a release, to catch regressions. Often there is nothing. The most I spend is maybe five to ten minutes fixing some minor things. Some of those minor things have nothing to do with C versus C++ like signed/unsigned warnings.

Note that these signed/unsigned warnings from GNU C++ actually found a real problem: I had code which assumed WEOF was negative. (It was originally char based code that was switched to wchar_t; of course EOF constant in the narrow character world is negative.) The GNU C++ compiler also identified the situation in the same code that a variable that should have been wint_t was mistakenly int.

The classic struct hack looks like:

  struct header {
    size_t size;
    char data[1];  // not [0]
  };

Automatic void casts are a misfeature in both languages; more so in C. In code that I control, I use a pointer to a character type as an "any memory" type, so that it requires a cast in both directions:

E.g.

  typedef unsigned char mem_t;

I use macros for casts, which compile to the classic C cast in C, and the more restricted casts in C++:

  #ifdef __cplusplus
  #define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
  #define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
  #define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
  #else
  #define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
  #define convert(TYPE, EXPR) ((TYPE) (EXPR))
  #define coerce(TYPE, EXPR) ((TYPE) (EXPR))
  #endif

The stupid void star thing and its conversion rules should never have been invented. C++'s treatment of it is more sane, at least, by working without a cast in only one direction.

What's really awful is official API's that use void star for opaque handles. The Kronos Group's OpenMax is one of these. You can mix up different kinds of handles for different objects and the calls will compile.

That's like your opinion, plenty of C programmers worth their salt would disagree with you.

Look, I'm not saying it's impossible to write code that compiles both as C and C++. The same is true of many other languages. The point is that you can't write C and expect it to be valid C++, which was the only thing I claimed.

Then my project grows to the point where I need to do some simple string operations.

At which point I remember the wonderful simplicity of garbage collected, high level languages...

A modern C++ compiler will have all sorts of issues with fundamental C idioms, and depending on C++ is a very different story from depending on C.

I maintain a significant body of code which compiles as C or C++. The executable size and performance are about the same.

A C++ compiler will, of course, have "issues" with C99 and C11 features, that's for sure.

Here let me note that I have not gone out of the way to disable anything in C++. I have not disabled EH in the compiler, or RTTI or anything. Yet, the executable size is close to the C one, and the performance is basically the same.

well, did you know that for instance the windows C library was implemented in C++ ? and yet we don't see it throwing exceptions left and right.

  /**
   * GCC and Clang extension to call cleanup function at exit
   * from the function with pointer to given function as argument.
   */
  #define defer(func) __attribute__((cleanup(func)))

  #ifdef _CRUST_TESTS
  
  // Sample destructor, to test defer
  static void _tst_charp_destroy(char * * value) {
    if(*value) {
      free(*value);
      *value = NULL;
    }
  }
  
  // Test case
  it(defer, "must deallocate object at the end of the function") {
    defer(_tst_charp_destroy) char * s = calloc(1, sizeof(char));
    (void)s;
  }
  
  #endif

D has scope(exit){...} which is similar to constructs like defer {...}

Many things can be done in some form with macros and the C11 generic keyword if they have to be, but defering statements to run on scope exit is still elusive as something that can be relied upon.

https://tour.dlang.org/tour/en/gems/scope-guards

Many programmers like myself have no problem with it whatsoever.

Change in a key infrastructural component like this is only destabilizing.

The ISO C people should have the decency to disband and work on their pet language research projects in private.

Adding simple abstractions which don't hide complexity in the underlying assembly is a huge productivity and correctness boost. Not that it matters anyways; modern optimizers are always going to do things that absolutely bend your brain.

Wouldn't that be nice if you could use a `scope(exit) {}` instead of accidentally missing two or three `goto cleanup_7;` which result in an RCE?

I would absolutely love a standards-compliant way to scope-guard sections of code. It'd make huge swaths of C code simpler; it's even in enough demand that Clang and GCC implement as their own extensions.

I can gladly provide a couple of examples.

Regarding C++:

- auto changed its meaning on C++11

- export templates were removed in C++11

- exception specifications were deprecated in C++11, removed in C++17 and might do a come back in C++23 with value based exceptions

- gets() got removed in C++11

- declspec and auto had a small semantic difference, settled in C++17

- initializer lists introduced in C++11 changed their auto deduction type in C++17

- the required implementation semantics for std::string in C++11 broke COW in compilers like GCC.

Just a small list, there are a couple more.

Also the draft C2x standard does away with K&R declarations, which will be another compatibility break.

Alright. Glad we cleared this whole thing up.

Nope; I will be writing in "it". What you obviously want is to be writing in something other than "it". You basically want to be able to write Rust, Go or D into a file that has a .c suffix and is passed through a preprocessor.

There's no evidence of this. There's just existing code. Ok. There's existing code in lots of other languages with different syntax (large and small differences). So what?

The latest video about Oden was a fantastic primer on QoL changes that should be standard, but there are people who always think what they learned is optimal. These are the same people who trivialize evidence to the contrary, in defense of their particular viewpoint.

The only guaranteed way your compiler won't break your code is if it's left alone.

Also, gratuitous changes to the compiler can break things that affect C90 operation. There is a risk.

The issue with cleanup on scope exit is that this introduces ambiguous code-flows. You would need to demonstrate a strong advantage, beyond making life easier for the writer of the code.

EDIT: Sorry for the confusion, I misread the article and thought this was about C++2x.

If they would add that feature, you could use macros to get constructor and destructor like behavior (as long as it's within the same scope, you could write a macro that constructs your object, and in addition contains something like "at scope exit: run this function"), which would be super useful and as far as I'm aware not very complex for the compiler (as all they have to do is run some code whenever exiting scope) nor very far outside of the spirit of C (it's still very low level, just a small convenience feature with interesting implications, especially when used with macros).

This idea doesn't seem to be in that spirit to me. It's not trying to do something radical like, say, adding OOP semantics to C. It's suggesting that C, a structured programming language, get a feature designed to improve the ergonomics for people doing structured programming in C.

But then you also want templates of course to get rid of your void*. And oh, wait, what's that? A cross-platform thread implementation (well, sort of, depends on platform)? A string thing which I can search without strstr? Anonymous functions which capture? Auto? Gimme gimme :]

C++ is not a strict superset of C. You actually have to cast void pointers, for example.

> But then you also want templates of course to get rid of your void*.

No, actually, I think I can live without that, but thank you.

> And oh, wait, what's that? A cross-platform thread implementation (well, sort of, depends on platform)?

C11, threads.h. Been there, got that.

> A string thing which I can search without strstr?

Okay, I'll give you that, string handling is hell.

> Anonymous functions which capture?

Have their uses, but I'm not sure if C is really the right place for it.

> Auto?

auto (as used in C++11 and later) is a solution in need of a problem in C. When you don't have piles of templates and iterators, you also tend not to need to automatically derive types. In a world where signed/unsigned integer comparison can have fatal consequences, you probably do want to be very sure about your types.

I know that. I use both C and C++ practically daily. The post was partly joking. But only partly (for example of course I could live without templates if really needed but seriously they make some jobs a lot better and easier). Hence I aptly phrased it some kind of C hoping (idly it seems) no one would trip over it because it's obviously not C.

I think you flipped this :) ?

Because some platforms I've used it on did't have proper C++ support. Or because a project I contribute to is already written in C. Or because of limited resources. Etc.

I'm not really understanding how wanting one little thing from C++ implies diving all the way in.

It's just an example of a possible train of thought. And I wouldn't call something like templates 'one little thing'. So suppose there's a choice between both, and no limit on resources etc, and I could go for everything C but templates could make everything easier then just going for C++ instead is an option. Even when not going 'all in' and writing what looks like standard C + template support.

Agreed. But templates aren't the one little thing, they're something you said would be 'next'. The 'one little thing' is a way to replace the GOTOs used for releasing resources. I think it's an easy argument that when people are repeatedly building a pattern out of GOTO, there's a gap in the control flow tools that a language gives you.

auto was already in vanishing disuse in C at the time ANSI C came out in 1989.

The C++ use of auto resurrects an aspect of the way auto was used in the C predecessor languages B and NB.

In these pre-C languages, everything was an integer cell. A declaration of local variables looked like this:

   auto x, y;

This implicit typing survived into C for "implicit int" return values, like "main () {...}". But type specifiers were introduced and became mandatory in declarations, and so auto became unnecessary verbiage since all it did now was specify a storage class that was already the default one.

C++ resurrect the syntactic use of auto in a way: once again, it provides declaration syntax that allows the type specifier to be omitted. This time, of course, that type is inferred rather than assumed integer.

https://stackoverflow.com/questions/2053029/how-exactly-does...

But who are we to ask..? Just programmers, i.e. mere mortals nobody really cares about. :-)

  // WTFPL
  class Finally {
    std::function<void()> f;
  public:
    Finally(std::function<void()> f) : f{f} {}
    ~Finally() {f();}
    void disable() { f = [](){}; }
  };

  socket* s = open_socket(); // or whatever
  Finally cleanup_socket{[](){ close_socket(s);}};

  // optionally, to keep it alive:
  cleanup_socket.disable();

    auto cleanup_socket = make_scope_guard([&]{ close_socket(s); });

  std::pair p{"aaa", 123};

  Finally guard{[]{cleanup();}};

[1] https://en.cppreference.com/w/cpp/language/class_template_ar...

Are you implying that people who want new features in C should just migrate to C++ because it has even more features? Or that C is perfect as-is and anyone who wants to add new features to it should bug off to another language? Or that this particular feature is somehow equivalent to (or a slippery slope toward) adding a whole set of OOP features to C, so we might as well take that to its logical conclusion?

A single, clearly articulated response would do a lot more than a fusillade of terse barbs to help others understand why you think this is a bad idea.

C is a great language, and I love working with it. But constexpr is something I really feel would improve the language (by eliminating the need for complicated #define macros). C++14's constexpr was a breath of fresh air when I first used it. It basically lets me write real code which evaluates at compile-time and can generate constants. I'd love to see constexpr ported over to C.

I feel like it has tons of applications, especially for embedded C programmers. One example that comes to mind: CRC calculation. Most microcontroller CRC libraries are lookup-based, or a mixture of a lookup table and other methods.

Currently, a lookup table can be done only 3 ways in C: pre-compute it and store 'magic numbers' (either while developing, or with some custom pre-processing), compute at program initialization (which costs code-space and startup time), or a compile-time computation based on some very ugly macros.

With constexpr support, I could just write a C function that calculates the table values. Then I could use it to populate a constexpr table at compile time, or even use the function at runtime if I needed to do some debugging.

C already has sizeof, which is a compile-time computation. Why not let users write their own compile-time functions too?

I recently wrote a command-lookup library in C++14. Using constexpr, I could precompute the hashes of each string and populate a switch() statement. Plus I could use the exact same function to hash my incoming strings, even if they're of unknown length. That's not possible in C at all, not even with loop-based macro trickery.

Fernando Boretti: https://github.com/eudoxia0/cmacro

Looking forward to this one, specially since Annex K ( Bounds Checking Interfaces) has proven to have not solved anything and is now scheduled for possible removal.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm#ad...

These other ones are also interesting from security point of view.

> Add a new calling conventions with error return for library functions that avoids the use of errno

> Extend specifications for enum types

> Add a simple specification of nullptr, similar to C++

It has solved the usual bounds errors on those who use it. I.e MS, Embarcadero and safeclib. Since glibc, musl and freebsd libc refuse to use the Annex K it's easy to blame just them, not the safe extension, which do serve their goal.

With safeclib you even get compile-time checks, more than with the simple _FORTIFY_SOURCE=2 checks. Only Android Bionic got a bit better lately. safeclib is as fast or even faster than the fragile assembler bits in glibc.

> Add a new calling conventions with error return for library functions that avoids the use of errno

That's of course part of Annex K.

What's urgently missing is still a proper string API. ASCII str* goes nowhere, wide char wcs* is not widely used, 80% use utf8. wcslwr, wcsfc, wcsnorm are even missing. The whole u8* string API is missing, and not even discussed. ICU, libutf8 and libunistring don't get you far. coreutils still cannot handle non-ASCII strings.

A situation which is described on the field report I linked to.

Only C++ compilers like Visual C++ which provide overloaded versions of Annex K without size parameter thanks to the improved C++ type system, do actually provide a real usable version of Annex K.

But then it isn't C anylonger.

That's wrong, check the implementation.

C++ only has advantages because there g++ is not as broken as gcc with constexpr, but clang since 5.0 is doing fine.

https://github.com/rurban/safeclib

It is perfectly viable to have a 100% ISO C99/C11 compliant compiler that will happily overwrite the target buffer, read more bytes than actually exist or search the whole memory block for a '\0' terminator, because Annex K does not require the existence of the compiler extensions used by your safeclib.

But neither ISP nor POSIX require _FORTIFY_SOURCE neither which uses the same object_size (bos) CHECKS. The alloc_size builtin or the CPU supported bounds checks are not used at all with the major libc's.

Problem is not the Annex K, but the refusal to implement and use it. There's no problem with state as in errno or locale. The criticism is easily debunkable. It's outright NIH bias.

Apparently at least Android might adopt it on ARM.

And do concede, maybe the extensions you have used, to actually become part of Annex K as well instead of deprecating it.

Because despite my dislike for C, I am fully aware that UNIX derived platforms will stay with us for the years to come, so we need to improve the current state of affairs somehow.

Since this as a whole is among the least consistently implemented and (arguably based on the number of questions it generates) least well understood aspects of the standard it's nice to see some authoritative efforts to clarify the intended behaviors.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2294.htm

As in a standard alloca?

Not sure about the Small C dialect from early 80's.

https://gustedt.wordpress.com/2016/08/17/effective-types-and...

arc4random is in complete POSIX limbo as far as I can tell. First started as a rename to posix_random[1] and then OpenBSD slammed the door shut by withdrawing it and now we're at risk of getting the worst of both worlds with Linux's getrandom[2].

[1] http://austingroupbugs.net/view.php?id=859

[2] http://austingroupbugs.net/view.php?id=1134

This alone will make C incompatible with its original platform, PDP/11 where char is either 7 or 9 bits.

C didn't run on the PDP-7.

Being either 7-bit or 9-bit would be a choice for 36-bit hardware. Wikipedia's list of 36-bit hardware is: MIT Lincoln Laboratory TX-2, the IBM 701/704/709/7090/7094, the UNIVAC 1103/1103A/1105 and 1100/2200 series, the General Electric GE-600/Honeywell 6000, the Digital Equipment Corporation PDP-6/PDP-10 (as used in the DECsystem-10/DECSYSTEM-20), and the Symbolics 3600 series.

Truncation can cause security bugs, and it is generally awful behavior. There is no silver bullet here: the programmer must not be a dummy about buffer sizes. Pretending otherwise is unhelpful.

Even better (someone please correct me if necessary) why isn't the very concept of "undefined behavior" completely removed? What good does it accomplish in a language?

You mean CHAR_BIT==8 as mandated by POSIX?

1. CHAR_BITS == 8, and

2. the compiler is required to make uint8_t an alias of unsigned char.

Point 2 is there so that you can cast to uint8_t safely, which some cryptographic code tends to rely on. If uint8_t is just any integer type, there's no safe cast to uint8_t due to strict aliasing rules[1]. That's what I want to fix. CHAR_BITS == 8 if uint8_t exists is just a collateral.

[1] https://cellperformance.beyond3d.com/articles/2006/06/unders...

Both are fine. For modern code with no global state, especially the multithreaded kind, everything is better than the errno.h mess.

In fact there's a Charter describing it better than I can:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm

Now, how do those error-related proposals violate it? Such as:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2289.pdf

It seems to be very delicate about being backwards-compatible.

errno.h isn't so much builtin to C. It's just part of the standard libary, and more so of POSIX. It's only used for interfacing with the OS. And it's not that bad, since errno is a thread local variable.

Yes, errors are just data. And everything is data, including the code itself, right? It a question of abstractions introduced to the language and the program at question.

errno.h is bad. It's inconvenient, it's global, even if it's a thread-local something, it's cumbersome to use.

AFAIK, there are 2 error-related proposals for inclusion. One is making errors special, the other is a bit more generic. Both would improve on the current situation.

> It a question of abstractions introduced to the language and the program at question.

I don't think these kind of abstractions are in the spirit of C. As it says in the Charter linked here, "provide only one way to do an operation".

A more acceptable way to me would be allowing multiple return values in general. But maybe there are technical reasons why this is not done. Or it has to do with the complexities that such a mechanism would add to the expression syntax.

This could certainly be made more general, or just done via tagged unions (the way multiple return values can be done via structs), but there are massive advantages to be had by building it into the language and calling convention.

The implementation can be far more efficient than any of a) the standard `int f(ret *out)` idiom, b) using errno, or c) some sort of `struct my_tagged_union f()` (which nobody uses anyway because it's a huge pain syntactically). In addition to being cheaper, the proposed built-in version of (c) is also syntactically simple enough to become a standard, shared mechanism.

Really, really hard to believe. Not only since returning unions is already legal (isn't it)? What function do you have in mind where an explit error-return-pointer argument is not close to maximally efficient?

The second problem is that existing calling conventions for `struct { bool tag; union { .. }; }` put everything in memory anyway, using a hidden pointer argument. Further, there's no way to put this type in the standard library because C doesn't have generics.

The new implementation can put that single-bit tag in the CPU's carry flag where it has dedicated branch instructions and doesn't interfere with other values. It can leave the actual return value in a register without any kind of union aggregate lowering.

So far this is all just calling convention tweaks, and could be done by pattern-matching user-defined tagged unions, but building it into the language a) makes it possible to standardize its semantics and connect it to platforms' C ABIs so other languages can also participate and b) makes it far simpler to implement and use so it's actually likely to be adopted.

The same reasoning applies to putting effort into register allocators, or switching from setjmp/longjmp to table-based unwinding, etc.

You need to make sure that you keep the size and complexity of the language and its specification within reasonable limits. So you can't just add "all of them" with a blanket statement that they will add up.

Unfortunately the discussion around N2289 is more about providing something a lot like exceptions for both C and C++ but without all the exception problems.

The proposal really has some ugly corners related to how one actually handles the errors. You can read the discussion here:

https://www.reddit.com/r/cpp/comments/9owiju/exceptions_may_...

You cannot take sizeof a function, and you can't copy functions around, for instance. The address of a function is a value ("data"), but not the function itself.

But that only strengthens the point: language features are just abstractions we use to reason about data. One can always strip all the abstractions and end up working with raw bits.

If there's a useful way to think about certain kinds of data - it might be useful to codify that way as a language feature. Such as specialised error handling.

  (let ((counter 0))
    (lambda () (incf counter))

Now suppose we had a copy-function library function. I would expect it that if we apply it to this function, we get an object which carries a duplicate of the lexical environment. This means it has its own instance of counter. If we call the original function, the copied function's counter stays the same and vice versa.

I don't remember seeing such a copy-function in any Lisp dialect; there isn't one in ANSI CL. It seems it might be useful, same as the ability to copy a structure or OOP object.

Conditional compilation is just a compatibility workaround to them.

I do like how Go does the posix interface where errors are handled as multiple return statements and cleanups using defer.

I mean, security trumps convenience and uptime, right guys? Y'all do build your functions with domain and range in mind, right guys?

Not in a heart-lung machine, no.

It is not used for reporting. Rather, various functions in C and POSIX return an indication that some exceptional situation has occurred. Then errno holds a value which classifies the cause of that situation. It doesn't report the error.

(In the case of portable ISO C, we can't even depend on that; we must set errno to zero before calling most library functions. If that function fails, then if errno is nonzero, it has a value pertaining to that function.)

Some newer functions in POSIX return the errno value, like pthread_mutex_lock. That makes sense when the return value has no other purpose like "bytes processed" or whatever. The errno values are positive, so they combine poorly with in-band signaling.

Anyway, optimizing is possible based on the return value: like putting the expected success case into the hot code path or whatever.

Optimizing errno is so easy that many compilers by default do not even update errno for many math functions because it hopelessly destroy any chance of vectorizing and aggressive optimizations.

  if (library_function(arg).result < 0) ..

  struct error;

  error = library_function(arg);

  // test error.result; if bad, work with error.num

I agree that errno for math functions isn't such a great fit. It's much better suited for I/O and resource management.

    match library_function(arg) {
      Ok(num) => // success
      Err(errno) => // failure
    }

  struct error res = library_function(arg);
  if (res.result)
  {
     // use res.errno
     ...
  }

  auto [result, errno] = library_function(arg);
  if (result == -1)
  {
     // use errno ...
  }

It's just a macro for a function like:

  #define errno (*__get_errno_location())

Does anyone have more information about this proposal?

C actually comes pre-equipped in a pretty nice position with its default 8 bit char data type (which is perfect for UTF-8).

The POSIX standard however, I agree is in serious need of an overhaul for locale features and you‘re probably better off ignoring it completely and just going ICU these days anyways - though then you have to go the extra length to still use the OS provided means (LC_* env under Unix) to get to the user‘s preferred locale.

But once you have that, yeah, ICU is probably the way to go for actual string formatting.

The reason there is a "standard library" is to make portability possible.

they're proposing to add u8 as a character constant prefix.

There are C++2x proposals to add a green thread/goroutine style mechanism. I'm not convinced that it's something which belongs in the C core language or C standard library though.