<d_bot>
<Patate> It should be. It's just a simple ml/ocamllex/menhir program that parses from an `in_channel`.
<d_bot>
<Patate> It then writes the corresponding `ctypes` bindings in three `out_channel`, that correspond to three files, for example `constant.ml`, `type.ml` and `function.ml`.
<d_bot>
<Patate> These files describe what has to be bound in the C library, and dune then does some magic to transform them into modules that you can use.
<d_bot>
<Patate> These modules expose the constants, data structures and functions that you need to use the C library.
<d_bot>
<Patate> I will use it on the vulkan library's header to learn Vulkan without having to write my programs in C.
<d_bot>
<Bluddy> very cool
<d_bot>
<Bluddy> I think some hacks have been made for libraries so far, but it'd be really nice to have a methodical tool that does it
<d_bot>
<Patate> It makes low-level bindings though.
mro has joined #ocaml
<d_bot>
<octachron> Part of the issue is that the C type system is not expressive even for the need of the C programmers.
<d_bot>
<Patate> Does not extract information such as an int field followed by a pointer field, the int field being the size of the array
<d_bot>
<octachron> Typically, the vulkan api has some functions that take an option type encoded as "if this bool argument is false, the following argument is nonsensical"
rgrinberg has joined #ocaml
mro has quit [Remote host closed the connection]
<d_bot>
<Patate> Yes, the cool thing about the language being so limited is that there is not much to learn in order to use it ^^
mro has joined #ocaml
<d_bot>
<NULL> You mean you don't have to learn much for C ?
rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<Patate> Yes
mro has quit [Remote host closed the connection]
<qwr>
not entirely true, the amount of footgun traps C programmer needs to learn is impressive
<qwr>
but the C's undefined behaviour related traps are also quite impressive
zebrag has joined #ocaml
<d_bot>
<octachron> The catch-fire-on-undefined-behaviour optmisations of modern C compilers are also fun from afar.
mro has joined #ocaml
<d_bot>
<Patate> I was meaning that the tool is simple. Using it is not. It's like an axe, dead simple and efficient, but easy to cut yourself with.
<companion_cube>
an axe where the handle is also sharp, yes
<d_bot>
<Patate> You are exaggerating ^^
<companion_cube>
absolutely not :D
<olle>
lulz, "C is simple" trope :D
<olle>
ASM is simple too?
<companion_cube>
for sure
<companion_cube>
well I guess asm doesn't have UB, does it?
<olle>
No idea
<olle>
Ask the CPU?
waleee has joined #ocaml
<olle>
If all behaviour is even documented
<companion_cube>
I think it's supposed to be all documented, even the memory model
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<companion_cube>
certainly, what happens if you divide by 0, access memory outside an existing page, etc. is documented
<olle>
Hm
<octachron>
weak memory models don't document everything that can happen on races, but only which behaviors(ordering) are guaranteed
<companion_cube>
mostly it's going to raise some trap and go back to the kernel ;)
<companion_cube>
octachron: sure, that's already a lot more than what C guarantees :D
<companion_cube>
there's a precise model, it's just not always deterministic.
<Corbin>
Depends on the chip vendor, too. Some chips (e.g. most x86 chips) are fully-documented due to explicit reverse-engineering effort which was not vendor-supported. Is it UB if it's not in Intel's manual, but it is on https://www.sandpile.org/ ?
<d_bot>
<Patate> it helps to turn on all warnings. I usually compile with -Wall -Wextra -Werror
<octachron>
C does have a specification, it is just that modern C compilers have decided that the specification means that worthy programmers shall not commit undefined behaviors. And that the unworthy are doomed to suffer.
motherfsck has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<Patate> It seems reasonable to me. Nice to know how to code before even thinking about perf
<companion_cube>
ugh, I don't have the patience for that today
mro has quit [Remote host closed the connection]
<olle>
Just don't write any bugs, duh
<d_bot>
<Patate> Patience for what?
<companion_cube>
patience for arguing about C
<d_bot>
<Patate> simpler said than done
mro has joined #ocaml
<d_bot>
<NULL> And that's why C is painful
<olle>
"If you made a mistake, you didn't try hard enough" <--- Some middle-manager ;)
<olle>
AKA hindsight bias
<d_bot>
<Patate> Ouch ok I see your point, that's not what I meant
<d_bot>
<cod1r> no pain no gain 🤣
<d_bot>
<Patate> C is not simple to learn/use, it is just simple as a language
<d_bot>
<Patate> And VERY error prone
bartholin has quit [Quit: Leaving]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<octachron> @Patate some people tend to somewhat disagree that `int n; while (n) {}; return n` is a simple and valid way to return `0`.
<companion_cube>
:DDDDD
<companion_cube>
only with -O1
<d_bot>
<Patate> you can write uselessly complicated code to do simple things indeed. But that is not on the language...
<d_bot>
<Patate> And it rises a warning
<d_bot>
<Patate> always listen to warnings ^^
<d_bot>
<Patate> If you want to survive using C
dextaa4 has quit [Remote host closed the connection]
<Corbin>
It's not uselessly complicated, as in `unsigned n = 1; while (n++) {}; return n`; octachron is pointing out that the infinite loop could be legally removed by the compiler and replaced with a terminating expression.
<Corbin>
(Whereas my example is merely implementation-defined, which is also extremely dangerous~)
<companion_cube>
yeah it's a fun example
<companion_cube>
it's legal to assume that n==0 because otherwise infinite loop :D
<zozozo>
funnily, it reminds me of some of chemistry classes which went like this: let's assume this quantity stays small, do some calculus, and we conclude that this quantity inded stays small, so we must have made the correct assumption at the beginning, :p
mro has quit [Quit: Leaving...]
<companion_cube>
riiiight?
<companion_cube>
always bugged me
<d_bot>
<Patate> if code can be stripped, it should... I guess... you think it should do the loop until it comes back to 0?
<Corbin>
zozozo: Funnily enough, you can make that work. You just have to show that if the quantity is big, then it gets small; and also that "big" and "small" are the only two regimes. The last part is the part that doesn't work for Turing-complete languages.
<d_bot>
<KW78> I think co-induction is like that - mind-blowing
dhil has quit [Ping timeout: 256 seconds]
<companion_cube>
@Patate a normal interpretation of the loop is that it's infinite; it doesn't change n
<companion_cube>
but infinite loops are UB, so the compiler just assumes you meant that n=0
<zozozo>
Corbin: yeah, it can be made to work (also, you can argue that chemistry at that scale is deterministic, and thus there exists exactly one coherent solution, so if you find one, then you have found the only solution)
<d_bot>
<RegularSpatula> Well it doesn’t bother with the check at all right, since it knows f1() is 0 ?
<d_bot>
<Patate> except if I am missing something, it does not
domq has joined #ocaml
domq has quit [Client Quit]
<d_bot>
<Patate> it just strips the loop as n = 0
<d_bot>
<NULL> `f1()` either loops or returns 0
<d_bot>
<NULL> `main` returns 42
<d_bot>
<Patate> if you replace the loop with while(n-5) it just runs forever
<d_bot>
<NULL> `f1()` should* loop or return 0; in practice it just returns 0
<d_bot>
<Patate> yes
<d_bot>
<NULL> But the question is why does `main` always return 42 (without checking `argc`)
<d_bot>
<Patate> Oh ok see it now
<companion_cube>
so simple!
<d_bot>
<Patate> Confusing... I print argc, it is > 2 but it just does not care for the test
<d_bot>
<Patate> Think I got it. as n is uninitialised, it chooses it's value whenever it wants. in the loop, it's 0, and as it has not been changed, it is still uninitialized, after the loop it is magically 42
<d_bot>
<Patate> Does not make any sense, but relying on an uninitialised value neither
<d_bot>
<Patate> so why not
<d_bot>
<NULL> How about using an uninitialised value is an immediate compiler error, instead of all of this nonsense ?
<Fardale>
Hum, if you replace the condition with argc you get the same result
<Fardale>
But puting 1 you get 0
<Fardale>
So f1 return 0 according to the compiler. Which makes sense, value on -01 are zero out
<Fardale>
but why does it consider argc = 0, this I don't know
<d_bot>
<RegularSpatula> (I think…) Compiler sets n to 0 to avoid undefined behavior of infinite loop. Then it can statically known that f1() is zero so it can slide the conditional …it is always false so it is always 42 at the optimization level on the godbolt snippet ccube posted
<d_bot>
<RegularSpatula> (Sorry for phone induced typos)
<d_bot>
<Patate> -Wall -Wextra -Werror
<olle>
Too much C in this channel...
<d_bot>
<Patate> C is full of undefined behaviour that are unfortunately NOT errors
<d_bot>
<Patate> sorry for that, I started it ^^ don't ban me
<Fardale>
If you remove the while(n){} it is still returning 0
<Fardale>
Just -01 zero the variable, I think you need -02 or -03 to not
<d_bot>
<RegularSpatula> Ohh snap I was looking at it wrong 😑 nvm
<d_bot>
<RegularSpatula> I thought the f1 was part of the check for some reason
<Fardale>
Oh, OK, because of the undifined behavoir the value return by f1() can be whatever, and then it decide to be 42.
<Fardale>
But for the compilation of f1() it chooses 0 by default
<Fardale>
That's my guess on this
<companion_cube>
yeah I think so too
<companion_cube>
the UB propagated to the main
<d_bot>
<Patate> For short, C is full of undefined behaviours. It is not simple to reason about (as 4 lines can make people talk for 15mins), and very easy to do errors. But it's syntax is simple (for parsing for example)
<companion_cube>
not even that
<companion_cube>
the syntax could be a lot easier to parse, and there's the preprocessor
<companion_cube>
if you want a simple language to parse, I hear pascal is one :p
<d_bot>
<Patate> maybe
<d_bot>
<octachron> The syntax is horrible too: it is not even a context-free grammar.
<d_bot>
<Patate> Oh?
<olle>
Patate, I once was in your shoes
<companion_cube>
you need type info to disambiguate, iirc; at least in C++, but ofc C++ is much worse
<olle>
This channel shot me down hard
<d_bot>
<NULL> To me the only thing C has going for it is that it's *very* close to assembly
<d_bot>
<Patate> ?
<d_bot>
<Patate> yes
<d_bot>
<darrenldl> (irc doesnt show whom you are replying to btw, i think
<d_bot>
<Patate> seems like there are some on the net
<d_bot>
<Patate> What do you mean olle by "Patate, I once was in your shoes"?
dextaa4 has quit [Read error: Connection reset by peer]
dextaa4 has joined #ocaml
<d_bot>
<Lupus> how to force latest atd to emit 64-bit integer as integer in resulting json? starting from https://github.com/ahrefs/atd/pull/231 64 bit integers are encoded as strings by default...
<d_bot>
<Patate> olle, I will lok that up later, thanks 🙂
<d_bot>
<Patate> Oof no that is old way of binding
<d_bot>
<Patate> using ctypes is easier
<d_bot>
<Patate> but not as well documented :/
szkl has quit [Quit: Connection closed for inactivity]
MaterazziSan has joined #ocaml
MaterazziSan has left #ocaml [ERC (IRC client for Emacs 27.1)]
<d_bot>
<darrenldl> json does not support 64bit integer iirc
<d_bot>
<Lupus> JSON accepts arbitrary precision numbers, most implementations support 64-bit integers as integers
<d_bot>
<Lupus> interoperability choice should be on someone writing atd spec, it should not be enforced by atd, which is happening right now as it seems...