Even if your task is obviously hiding the ...
-to-C stage of translation from the user's eyes by letting the C compiler read your C BASIC header and use the BaCon library with or without the addition of MyAlloc for immediate compilation, you
will not get by with a C BASIC header file alone. You need much deeper parsing capabilities to efficiently translate
Dim ... As String and similar declarations and other BASIC language features to equivalent C.
Forget the header file. Write a simple recursive descent parser that would turn your canonical-BASIC "X BASIC" or whadayacallit sources into decent C equivalents without those horrible semicolons or neoteric BEGIN_FUNCTION placeholders. In short, go the BCX way and try to keep your "X BASIC" syntax closer to tradition.
I repeat I do not see any sense or benefit in C BASIC over BCX. The latter does a much much better job of converting a BASIC-style dialect to C. Replace BCX' ring allocator with your MyAlloc routines if you want to. What's the problem of forking the open-source GNU GPL BCX project for that if you wanna stay open-source all the way through yourself? Disgust towards that Kevin Diggins character?
Come on, John!
And you can simply add a BCX post-processing step of automatic C compilation and immediate deletion of intermediate C code files from your disk. What else would you want or should the user need and why?