4 ms·

A low effort question on what's C3 take on pointer provenance. Does C3 have any own take on it? Are you with C or with your implementation detail (LLVM) ? Also

A low effort question on what's C3 take on pointer provenance. Does C3 have any own take on it? Are you with C or with your implementation detail (LLVM) ? Also if you have 'tourist guide' for gamedev people please share links or short tips. I have no idea about C replacements myself because gamedev that I know is not using C. ps somehow in my part of the internet your blog is not accessible with cloudflare saying access denied. Do you have any copy/backup of it elsewhere?

Joshringuk 1y ago
@lerno is a ganedev himself so should be able to answer your question there Some links https://c3-lang.org/getting-started/ https://c3-lang.org/getting-started/ https://c3-lang.org/getting-started/design-goals/ https://c3-lang.org/getting-started/design-goals/ https://c3-lang.org/faq/compare-languages/ https://c3-lang.org/faq/compare-languages/ The blog is on the internet archive https://web.archive.org/web/20250330145704/https://c3.handmade.network/blog/p/9010-c3_0.7_released_-_one_step_closer_to_1.0#30446 https://web.archive.org/web/20250330145704/https://c3.handma...
lerno 1y ago
I don't have any particularly strong stance on provenance. But I've yet to see a strong argument for it in C. There is not much of a guide I'm afraid. I translated some of the raylib examples to C3: https://github.com/c3lang/c3c/tree/master/resources/examples/raylib https://github.com/c3lang/c3c/tree/master/resources/examples... But those are straight up conversions of the original C code. I think any C tutorial on gamedev would work fine to follow in C3, and then one can leverage features of C3 as desired.
- SleepyMyroslav 1y ago
  Judging from 'comparing pointers of different provenance' can produce 'any result' ( here https://c3-lang.org/language-rules/undefined-behaviour/#list-of-implementation-dependent-behaviours https://c3-lang.org/language-rules/undefined-behaviour/#list... ) everyone has to deal with it. More low effort questions. Question about optional debug traps: are they available in optimized builds? Are any LLVM sanitizers available? It usually means language needs to have APIs to mark up your own allocators/containers/etc. Does language help parallel/concurrent programs to be more readable?
  - joshring2 1y ago
    > Question about optional debug traps Contracts are available in safe mode, which can optionally be enabled for optimised builds as-well, yes. > Does language help parallel/concurrent programs to be more readable? There's active interest in working in this area, if you're interested to help you're welcome to suggest or contribute.
  - lerno 1y ago
    I think that one is a bit wrong, I must have written it many years ago. There are machines where pointers do have different address spaces, like the Arduino obviously, but that support isn't in the language yet, and maybe there might be issues there but comparing something like `int` and `float` pointers, that shouldn't be UB. I'll look at that text. Debug traps can be kept in optimized builds, you can always do something like "-O3 --safe=yes". Right now it's not possible to set it per function or module, but that might be added if there is demand for it. Because C3 also has contracts, the plan is to step by step increase static analysis to catch more of the contract violations at compile time. For example: <* @require a > 10 @require b < a *> fn void test(int a, int b) {} Will error at compile time for `test(5, 2)` (first @require), or `test(5, 10)` (second @require). These will also be checked at runtime, but catching low hanging fruits a compile time will be very helpful I think. LLVM address and thread sanitizers work. The memory sanitizer still has some issues but will be fixed. Currently there are just cross platform threads available and some rudimentary thread pools. This needs to be expanded and we'll see if there are things the language could help with but there will not be any async built in.
    - SleepyMyroslav 1y ago
      if you plan to look at pointer provenance please check recent HN discussions like this one ( https://news.ycombinator.com/item?id=42878450 https://news.ycombinator.com/item?id=42878450 ) and transitively links to source papers for C. TLDR (imho) C has failed to define pointer provenance but had to acknowledge its existence. LLVM and GCC have their own ideas on it which means their open issues on it are different. For practical languages aiming to be useful in embedded ie Rust there are complex workarounds: https://doc.rust-lang.org/std/ptr/index.html#exposed-provenance https://doc.rust-lang.org/std/ptr/index.html#exposed-provena.... What is relevant for C3 is that it is likely to be exposed to open issues from LLVM and people will need practical ways to solve them. ps Don't take my word for it. My tldr might be wrong because of my gamedev experience (like we dont ship products with GCC).

Joshringuk 1y ago

@lerno is a ganedev himself so should be able to answer your question there Some links https://c3-lang.org/getting-started/ https://c3-lang.org/getting-started/ https://c3-lang.org/getting-started/design-goals/ https://c3-lang.org/getting-started/design-goals/ https://c3-lang.org/faq/compare-languages/ https://c3-lang.org/faq/compare-languages/ The blog is on the internet archive https://web.archive.org/web/20250330145704/https://c3.handmade.network/blog/p/9010-c3_0.7_released_-_one_step_closer_to_1.0#30446 https://web.archive.org/web/20250330145704/https://c3.handma...

lerno 1y ago

I don't have any particularly strong stance on provenance. But I've yet to see a strong argument for it in C. There is not much of a guide I'm afraid. I translated some of the raylib examples to C3: https://github.com/c3lang/c3c/tree/master/resources/examples/raylib https://github.com/c3lang/c3c/tree/master/resources/examples... But those are straight up conversions of the original C code. I think any C tutorial on gamedev would work fine to follow in C3, and then one can leverage features of C3 as desired.

SleepyMyroslav 1y ago
Judging from 'comparing pointers of different provenance' can produce 'any result' ( here https://c3-lang.org/language-rules/undefined-behaviour/#list-of-implementation-dependent-behaviours https://c3-lang.org/language-rules/undefined-behaviour/#list... ) everyone has to deal with it. More low effort questions. Question about optional debug traps: are they available in optimized builds? Are any LLVM sanitizers available? It usually means language needs to have APIs to mark up your own allocators/containers/etc. Does language help parallel/concurrent programs to be more readable?
- joshring2 1y ago
  > Question about optional debug traps Contracts are available in safe mode, which can optionally be enabled for optimised builds as-well, yes. > Does language help parallel/concurrent programs to be more readable? There's active interest in working in this area, if you're interested to help you're welcome to suggest or contribute.
- lerno 1y ago
  I think that one is a bit wrong, I must have written it many years ago. There are machines where pointers do have different address spaces, like the Arduino obviously, but that support isn't in the language yet, and maybe there might be issues there but comparing something like `int` and `float` pointers, that shouldn't be UB. I'll look at that text. Debug traps can be kept in optimized builds, you can always do something like "-O3 --safe=yes". Right now it's not possible to set it per function or module, but that might be added if there is demand for it. Because C3 also has contracts, the plan is to step by step increase static analysis to catch more of the contract violations at compile time. For example: <* @require a > 10 @require b < a *> fn void test(int a, int b) {} Will error at compile time for `test(5, 2)` (first @require), or `test(5, 10)` (second @require). These will also be checked at runtime, but catching low hanging fruits a compile time will be very helpful I think. LLVM address and thread sanitizers work. The memory sanitizer still has some issues but will be fixed. Currently there are just cross platform threads available and some rudimentary thread pools. This needs to be expanded and we'll see if there are things the language could help with but there will not be any async built in.
  - SleepyMyroslav 1y ago
    if you plan to look at pointer provenance please check recent HN discussions like this one ( https://news.ycombinator.com/item?id=42878450 https://news.ycombinator.com/item?id=42878450 ) and transitively links to source papers for C. TLDR (imho) C has failed to define pointer provenance but had to acknowledge its existence. LLVM and GCC have their own ideas on it which means their open issues on it are different. For practical languages aiming to be useful in embedded ie Rust there are complex workarounds: https://doc.rust-lang.org/std/ptr/index.html#exposed-provenance https://doc.rust-lang.org/std/ptr/index.html#exposed-provena.... What is relevant for C3 is that it is likely to be exposed to open issues from LLVM and people will need practical ways to solve them. ps Don't take my word for it. My tldr might be wrong because of my gamedev experience (like we dont ship products with GCC).