You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: crates/glue/writing_a_glue_plugin.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Writing a glue plugin
2
2
3
-
In order to write a platform, the language the platform is written in must know how to interoperate with Roc. As Roc is statically typed, the required FFI wrapper code must be tailored to the datatypes that form the FFI boundry between the host and the Roc application. Handily, the `roc glue` subcommand will take these types as defined in a `platform.roc` file and turn them into layout information. A glue plugin then in turn uses this to generate the appropriate source code in a target language. This layout information comes in the form of a data structure that requires some additional explanation.
3
+
In order to write a platform, the language the platform is written in must know how to interoperate with Roc. As Roc is statically typed, the required FFI wrapper code must be tailored to the datatypes that form the FFI boundary between the host and the Roc application. Handily, the `roc glue` subcommand will take these types as defined in a `platform.roc` file and turn them into layout information. A glue plugin then in turn uses this to generate the appropriate source code in a target language. This layout information comes in the form of a data structure that requires some additional explanation.
4
4
5
5
-[Writing a glue plugin](#writing-a-glue-plugin)
6
6
-[The Types data structure](#the-types-data-structure)
@@ -30,7 +30,7 @@ In order to write a platform, the language the platform is written in must know
30
30
31
31
# The Types data structure
32
32
33
-
`Types` is a data structure that stores the layout information of all types on the host-application FFI boundry for a specific architecture. This includes these types' size, alignment, order of declaration, and their `Shape`.
33
+
`Types` is a data structure that stores the layout information of all types on the host-application FFI boundary for a specific architecture. This includes these types' size, alignment, order of declaration, and their `Shape`.
34
34
35
35
# The Shape data structure
36
36
@@ -51,7 +51,7 @@ A number type. Either a signed integer (I8 through I128), an unsigned integer (U
51
51
## RocStr, RocList, RocDict, RocSet, RocBox
52
52
53
53
Roc builtin datatypes. The Roc compiler is planned to expose parts of the standard library to glue code via C FFI to avoid having the reimplement them by hand in every host language. In the meantime:
54
-
- The authoratitive Zig implementations for Roc builtins can be found under `crates/compiler/builtins/bitcode/src`. These are more made for use by the compiler, and thus are better used for reference than for human use.
54
+
- The authoritative Zig implementations for Roc builtins can be found under `crates/compiler/builtins/bitcode/src`. These are more made for use by the compiler, and thus are better used for reference than for human use.
55
55
- Rust implementations of the `Str`, `List`, and `Box` datatypes can be found under `crates/roc_std`. These are made for use by humans, and as such are a better example for what their wrapper APIs might look like. Do note that these are not guaranteed to be in sync with their Zig implementations.
(TODO: a `RecursivePointer` causes no code to be generated in `RustGlue.roc`, and is otherwise always treated as an instance of the type it's "pointing to", with no pointer indirection like the name implies. Is this shape vestigial?)
450
+
(TODO: a `RecursivePointer` causes no code to be generated in `RustGlue.roc`, and is otherwise always treated as an instance of the type it's "pointing to", with no pointer indirection like the name implies. Is this shape vestigial?)
Copy file name to clipboardExpand all lines: src/README.fuzzing.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,14 +50,14 @@ If the test case is complex or interesting, it likely is worthwhile to add a sna
50
50
51
51
For better fuzzing performance you will want to modify `std.mem.backend_can_use_eql_bytes` to return false, otherwise AFL++ will not be able to observe char-by-char string comparisons and its fuzzing capabilities will be greatly reduced.
52
52
53
-
This means modifying your copy of the Zig stdlib. If you have ZLS you can simply write `std.mem` anywhere in your code and goto definiton, otherwise you can invoke `zig env` and modify `$std_dir/mem.zig`.
53
+
This means modifying your copy of the Zig stdlib. If you have ZLS you can simply write `std.mem` anywhere in your code and goto definition, otherwise you can invoke `zig env` and modify `$std_dir/mem.zig`.
54
54
55
55
**Also don't forget to revert this change after you're done!**
56
56
57
57
## Advanced Usage
58
58
59
59
afl++ has a ton of bells and whistle to get way more performance and better results out of it.
60
-
The largest one is probably [running multiple copies of afl (preferrably with different configs)](https://aflplus.plus/docs/fuzzing_in_depth/#c-using-multiple-cores) to use all your compute power.
60
+
The largest one is probably [running multiple copies of afl (preferably with different configs)](https://aflplus.plus/docs/fuzzing_in_depth/#c-using-multiple-cores) to use all your compute power.
61
61
62
62
Probably the largest other gain is in keeping around and managing a corpus of examples.
63
63
This enables the fuzzer to build up more and more information about the target executable of different execution sessions.
0 commit comments