Live data from Hacker News

Giving C a superpower: custom header file (safe_c.h)

hwisnu.bearblog.dev

251–260 of 277 posts

Re: Giving C a superpower: custom header file (safe_c.h)

#251
post #176

Earlier quoted context omitted.

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

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.

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 ;)

Re: Giving C a superpower: custom header file (safe_c.h)

#252
post #23

> C23 gave us [[cleanup]] attributes C23 didn't introduce it, it's still a GCC extension that needs to be spelled as [[gnu::cleanup()]] https://godbolt.org/z/Gsz9hs7TE

It is surprisingly hard to find information about it, do you have any ? From what I can guess it's a new syntax but it's the feature itself is still an extension ?

C standard _may_ eventually have a feature semantically equivalent, but very different syntactically:

https://thephd.dev/_vendor/future_cxx/technical%20specificat...

Discussion:

https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Improve...

Re: Giving C a superpower: custom header file (safe_c.h)

#254
post #251

Earlier quoted context omitted.

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.

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 ;)

> 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!

Re: Giving C a superpower: custom header file (safe_c.h)

#255

Earlier quoted context omitted.

> I think an improved C can be memory safe even without GC That's a very interesting belief. Do you see a way to achieve temporal memory safety without a GC, and I assume also without lifetimes?

C does have the concept of lifetimes. There is just no syntax to specify it, so it is generally described along all the other semantic details of the API. And no it is not the same as for Rust, which causes clashes with the Rust people.

What clashes?

Re: Giving C a superpower: custom header file (safe_c.h)

#256
post #255

Earlier quoted context omitted.

C does have the concept of lifetimes. There is just no syntax to specify it, so it is generally described along all the other semantic details of the API. And no it is not the same as for Rust, which causes clashes with the Rust people.

What clashes?

I think there was a discussion in the Linux kernel between a kernel maintainer and the Rust people, which started by the Rust people demanding formal semantics, so that they could encode it in Rust, and the subsystem maintainer unwilling to do that.

Re: Giving C a superpower: custom header file (safe_c.h)

#257
post #251

Earlier quoted context omitted.

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 ;)

> 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 differen…

If you want to return some precalculated stuff w/o using malloc() free(). So you just have 8 preallocated buffers and you rotate them between calls. Of course you need to be aware that results have short lifetime.

Re: Giving C a superpower: custom header file (safe_c.h)

#258
post #255

Earlier quoted context omitted.

What clashes?

I think there was a discussion in the Linux kernel between a kernel maintainer and the Rust people, which started by the Rust people demanding formal semantics, so that they could encode it in Rust, and the subsystem maintainer unwilling to do that.

Ah, I thought you were talking about core language semantics in C.

Re: Giving C a superpower: custom header file (safe_c.h)

#259
post #258

Earlier quoted context omitted.

I think there was a discussion in the Linux kernel between a kernel maintainer and the Rust people, which started by the Rust people demanding formal semantics, so that they could encode it in Rust, and the subsystem maintainer unwilling to do that.

Ah, I thought you were talking about core language semantics in C.

I don't know enough Rust, to do such a comparison.

Re: Giving C a superpower: custom header file (safe_c.h)

#260
post #257

Earlier quoted context omitted.

> 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 differen…

If you want to return some precalculated stuff w/o using malloc() free(). So you just have 8 preallocated buffers and you rotate them between calls. Of course you need to be aware that results have short lifetime.

That sounds like a maintenance nightmare to me. If you insist on static, I would at least only use one buffer, to make it predictable, but personally I would just let the caller pass a pointer, where I can put the data.

What application is that for? Embedded, GUI program, server, ...?

Post reply on HN