Commit Graph

6 Commits

Author SHA1 Message Date
Benedikt Peetz 5a7bb00548
chore(treewide): Add the new license header 2024-02-19 16:13:55 +01:00
Benedikt Peetz 7ac6edb752
chore(treewide): Remove old license header
This was done with:
```bash
fd --type file . | xargs grep 'Copyright (C) 2023  The Trinitrix Project <soispha@vhack.eu, antifallobst@systemausfall.org>' | awk 'BEGIN{ FS=":"} {print $1}' | xargs sed -i '1,19d'
```
2024-02-19 16:13:48 +01:00
Benedikt Peetz b3c6a4c1a1
feat(treewide): Add broken Vec<E>, Result<T,E> and Option<T> types to c api
These are implemented right now by simply casting the generic arguments
to void pointers and providing a `type_id` field in every struct
denoting the original type.

This implementation, whilst being extremely unwieldy to work with on
the c side, also fails in a lot of fundamental ways:
   1. The `type_id` enum *can* never really support user defined
      types because we would already need it to provide the c to rust
      value conversion.

   2. Even without custom user types the type conversion is extremely
      hard to correctly implement in a somewhat performant way: A vector
      passed from c code to rust would need to completely reallocated
      *one element at a time*. And this only works if the c side has
      correctly cast the void pointer to the vectors data before accessing
      it, as any other way would have lead to possible unaligned data
      (which the rust side had to account for).

   3. The c api is just simply bad in this state:
      You have to always look at the Trixy file to even be able to deal
      with the data the api returns (that is: There is no mention of
      a results generics in the c header).  Additionally the question
      arises if these types should even be leaked into the c code because
      than c just becomes a worse version of rust, which undermines the
      whole reason of providing a c api in the first place.

One way to fix all these issues would be to change the way generics are
handled by using unions instead of the void pointer and trying to avoid
leaking these rust types in c as far as possible.
This approach would require a lot less binding code (both on the c and
rust side), but also would make the rust based c-header-gen-code harder,
as it would then be required to turn a `Vec<String>` to a `char **` (and
obviously a whole wrapper struct with size and string length), whilst
turning a `Vec<char>` to a `char*` differentiating it from a `string_t`.
2023-12-28 10:28:58 +01:00
Benedikt Peetz 21e1b75193
chore(treewide): Move the trixy subcrates under one trixy crate 2023-12-26 12:14:08 +01:00
Benedikt Peetz 7d1a41aca9
feat(treewide): Provide a c api 2023-12-25 22:23:52 +01:00
Benedikt Peetz ed96a50bd4
feat(trixy-macros): Add rust host code generation 2023-12-24 11:28:30 +01:00