[miroljub]

Nice toy. It works until it stops working. An experienced C developer would quickly find a bunch of corner cases where this just doesn't work.

Given how simple examples in this blog post are, I ask myself, why don't we already have something like that as a part of the standard instead of a bunch of one-off personal, bug-ridden implementations?

[brabel]

It would be a lot more constructive if you reported a bunch of corner cases where this doesn't work rather than just dismissing this as a toy.

[miroljub]

No, I don't dismiss anything.

It's just, I'd rather play with my own toys instead of using someone else's toy. Especially since I don't think it would ever grow up to be something more than a toy.

For serious work, I'd use some widely used, well-maintained, and battle-tested library instead of my or someone else's toy.

[Borg3]

Yeah, kids like to waste time to make C more safe or bring C++ features. If you need them, use C++ or different language. Those examples make code look ugly and you are right, the corner cases.

If you need to cleanup stuff on early return paths, use goto.. Its nothing wrong with it, jump to end when you do all the cleanup and return. Temporary buffers? if they arent big, dont be afraid to use static char buf[64]; No need to waste time for malloc() and free. They are big? preallocate early and reallocate or work on chunk sizes. Simple and effective.

[lukan]

Can you share such a corner case?

[Borg3]

No, because I did NOT do serious analisis of this. Nor I care, ask upper commenter.. C have some corner case and undefined behaviours and this stuff will make it worse IMO.

[1718627440]

> use goto

My thoughts as well. The only thing I would be willing to use is the macro definition for __attribute__, but that is trivial. I use C, because I want manual memory handling, if I wouldn't want that I would use another language. And now I don't make copies when I want to have read access to some things, that is simply not at a problem. You simply pass non-owning pointers around.

[1718627440]

> static char buf[64];

In a function? That makes the function not-threadsafe and the function itself stateful. There are places, where you want this, but I would refrain from doing that in the general case.

[Borg3]

Holy moly.. Thread safety.. Good point and Bad point. I myself use threads sparsly, so I dont intermix calls between threads..

[1718627440]

It also has different behaviour in a single thread. This can be what you want though, but I would prefer it to pass that context as a parameter instead of having it in a hidden static variable.

[Borg3]

What different behaviour you mean? static in function means that this is just preallocated somewhere in data, not on stack nor heap. Thats it. Yes, its not thread safe so should never be used in libraries for any buffering.

But in program, its not bad. If I ever need multiple calls to it in same thread:

  static char buf[8][32];
  static int z;
  char *p=buf[z];
  z=(z+1)&7;

Works pretty well ;)

[1718627440]

> What different behaviour you mean?

Static foremost means that the value is preserved from the last function invocation. This is very different behaviour, than an automatically allocated variable. So calling a function with a static variable isn't idempotent, even when all global variables are the same.

> If I ever need multiple calls to it in same thread:

What is this code supposed to do???? It hands out a different pointer, the first 8 times, than starts from the beginning again? I don't see what this is useful for!

[kstrauser]

God forbid we should make it easier to maintain the existing enormous C code base we’re saddled with, or give devs new optional ways to avoid specific footguns.

[mightyham]

Goofy platform specific cleanup and smart pointer macros published in a brand new library would almost certainly not fly in almost any "existing enormous C code base". Also the industry has had a "new optional ways to avoid specific footguns" for decades, it's called using a memory safe language with a C ffi.

[kstrauser]

I meant the collective bulk of legacy C code running the world that we can’t just rewrite in Rust in a finite and reasonable amount of time (however much I’d be all on board with that if we could).

There are a million internal C apps that have to be tended and maintained, and I’m glad to see people giving those devs options. Yeah, I wish we (collectively) could just switch to something else. Until then, yay for easier upgrade alternatives!

[mightyham]

I was also, in fact, referring to the bulk of legacy code bases that can't just be fully rewritten. Almost all good engineering is done incrementally, including the adoption of something like safe_c.h (I can hardly fathom the insanity of trying to migrate a million LOC+ of C to that library in a single go). I'm arguing that engineering effort would be better spent refactoring and rewriting the application in a fully safe language one small piece at a time.

[kstrauser]

I’m not sure I agree with that, especially if there were easy wins that could make the world less fragile with a much smaller intermediate effort, eg with something like FilC.

I wholeheartedly agree that a future of not-C is a much better long term goal than one of improved-C.