My advice is to compile to QBE, not worry about header compatibility
right now, and write up a tool to convert C headers to .hros when it
becomes necessary. If you feel like it, integrate said tool into
Crowbar's build system. Said tool should only parse a small subset of C,
let the programmer sort things out if the header file sucks in order to
avoid reimplementing C.

But, really, don't worry at all converting header files at least until
you have a self-hosting compiler. There are other, more important tasks,
like designing the language and implementing it at least twice. If you
want to use a C library before you write the translator, just do the
translation manually.

Also, some feedback on the memory safety spec:

- You're probably going to need to do something more complex to guard
  against use-after-free, the current system breaks with aliasing:

```
void *foo = malloc(1234);
void *bar = foo;
free(foo); foo = NULL;
*bar; // Game over
```

- I would require variable initialization in the syntax, rather than
  relying on C usually providing a warning
- How will crowbar prevent, say, `*(int *)0x12345678` (or a slightly
  less shady looking constant :P) from segfaulting?
- Your memory leak plan looks, uh, interesting

Looking forward to see what comes out of Crowbar :)

On 2020-10-20 12:20 AM, Eyal Sawady wrote:
> My advice is to compile to QBE, not worry about header compatibility
> right now, and write up a tool to convert C headers to .hros when it
> becomes necessary. If you feel like it, integrate said tool into
> Crowbar's build system. Said tool should only parse a small subset of C,
> let the programmer sort things out if the header file sucks in order to
> avoid reimplementing C.

Thanks for reaching out!
After writing my blog post and sleeping on it, I had settled on 
compiling to C, but that has its own mountain of benefits and drawbacks, 
and I could probably run that cost-benefit analysis for years and not 
finish.

Skipping C means there's more directly under my control, but it also 
increases the scope of the project by a lot. However, I was always 
planning to have a non-C compiler eventually, so the C layer is just 
scaffolding, and since it's at least an order of magnitude more 
complicated than QBE IR, I'm probably better off skipping it.

I think eventually, tools should exist to translate back and forth 
between .h and .hro files, but you're right that that's nowhere near the 
most important thing to work on.

> But, really, don't worry at all converting header files at least until
> you have a self-hosting compiler. There are other, more important tasks,
> like designing the language and implementing it at least twice. If you
> want to use a C library before you write the translator, just do the
> translation manually.

Yeah, if the linking process and everything all works the same, then 
manually authored .hro files should be fine, at least for a while.

> Also, some feedback on the memory safety spec:
> 
> - You're probably going to need to do something more complex to guard
>    against use-after-free, the current system breaks with aliasing:
> 
> ```
> void *foo = malloc(1234);
> void *bar = foo;
> free(foo); foo = NULL;
> *bar; // Game over
> ```

Ooh, yeah, that's pretty easy to do without deliberately trying to 
use-after-free. I'll definitely have to flesh that out a little more.

> - I would require variable initialization in the syntax, rather than
>    relying on C usually providing a warning

That's smart.

> - How will crowbar prevent, say, `*(int *)0x12345678` (or a slightly
>    less shady looking constant :P) from segfaulting?

Casting a non-pointer type to a pointer will be a compiler error.

> - Your memory leak plan looks, uh, interesting

"plan" is a generous term for it. Whatever I do to handle use-after-free 
more robustly will probably also spit out a compiler error if something 
looks like it never gets freed at all.

> Looking forward to see what comes out of Crowbar :)

Thanks! Your feedback helps make sure whatever I wind up with is worth 
looking forward to.

-💤🌵

On Tue Oct 20, 2020 at 8:33 PM EDT, boringcactus wrote:
> Skipping C means there's more directly under my control, but it also
> increases the scope of the project by a lot.

Better to do it the right way than to do it the easy way.

> Yeah, if the linking process and everything all works the same, then
> manually authored .hro files should be fine, at least for a while.

You'll probably need to manually specify the relevant `-l`s until you
get the build system working with C libraries, but besides that, it
should work fine.

Oh, and another thing I just thought of: you don't need to worry about
making sure that the runtime library exists on the host system, you
should be statically linking everything.

> > - How will crowbar prevent, say, `*(int *)0x12345678` (or a slightly
> >    less shady looking constant :P) from segfaulting?
>
> Casting a non-pointer type to a pointer will be a compiler error.

Non-pointer->pointer casts are required for kernels, which are an
important use-case for C and any C replacement.

On 2020-10-21 11:02 AM, Eyal Sawady wrote:
> Oh, and another thing I just thought of: you don't need to worry about
> making sure that the runtime library exists on the host system, you
> should be statically linking everything.
Picked up on that one myself eventually, but yeah, that's the right way 
to do it.

> Non-pointer->pointer casts are required for kernels, which are an
> important use-case for C and any C replacement.

I may have to soften the memory safety guarantees into memory safety 
probably-guarantees, i.e. it's possible to tell the compiler "I know you 
can't verify that this is safe, but I want to do it anyway."

Thanks for all your suggestions!