crashappsec / libcon4m

Base Compiler and Runtime Support for con4m
Apache License 2.0
0 stars 0 forks source link

Remove macos warnings #6

Closed viega closed 5 months ago

viega commented 5 months ago
  1. Minor clean up to remove all warnings that are spurious, so that this builds cleanly on macos now, minus one dependency meson acquires and builds for us (e.g., libunibreak).
  2. Re-built the critical parts of the con4m type system, and switched over con4m_new() to take typespec objects. This will make it easy for us to make sure that we can do run-time type checking whenever we need to do so. con4m_new() now takes a typespec object to figure out what to instantiate; see type.h for the interface, but for builtin types, the type is an index into an array of base type objects.
  3. Added a stream abstraction on top of FILE *, with the ability to do custom streams (I used it to do string streams, instead of fmemopen() and open_memstream() because it's not acceptable for open_memstream() to use the system alloc.
  4. Added object marshaling to a stream. Note that the object-level interface is intended to be called ONLY when we have an object; if we have a by-value type (mainly the numeric types, plus bools), then there's a separate API. This means that container types need to check their type when marshaling, and use whichever interface is appropriate as a result. However, that feels better to me than needing to box numeric types when we have type information around.
  5. I hooked up the type set_t (from hatrack), added tuple_t, stubbed out some of the remaining existing con4m types (callbacks, IP addrs). There are a few more things to do here, but actually think we might have everything covered that chalk currently uses. Besides more arcane types, the major exception in terms of the data structure API being ready to replace what's in Nim is literal parsing... none of that is done in libcon4m.
  6. I added in a mixed type so that we absolutely can support fully dynamic type checking where it's important. We don't necessarily have to expose this at the language-level, but I'm thinking yes.