"Invalid number of parameters error" for simple C file.

[hexagonal-sun]

"Invalid number of parameters error" for simple C file.

[hexagonal-sun]

If there's no return, can we drop into the REPL?

Sure, that sounds like a good idea. I'll see how difficult that would be to add.

Other languages make them available globally like you're talking about.

Yep, I think having them global makes sense. Of course whether they are available to 'nested' functions that are defined in the script depends upon the scoping rules that we choose.

As for someInt, I think it would be visible.

Agreed. I'll probably follow the rules the GCC uses for inline functions in C (see here).

I've just finished a major re-write of the parser (nearly 100 commits and over 2500 lines of code change) and so I'll be starting to look into this in the coming weeks.

[hexagonal-sun]

Hey @cjwelborn,

I've started looking at implementing support for cscripts. Take a look at the cscript branch and let me know what you think! So far I've managed to get this working:

#define _GNU_SOURCE
#include <string.h>
#include <stdio.h>

void writeFile(const char *s)
{
    FILE *f;
    f = fopen(s, "a");
    fputs("Hello, cscript!\n", f);
    fclose(f);
}

int i;
for (i = 0; i < 20; i++)
{
    char *fname;
    asprintf(&fname, "out%d.txt", i);
    writeFile(fname);
    printf("Wrote: %s\n", fname);
}

printf("wrote %d files!\n", i);

return 0;

Test with: bic -s test.csh. Notice that there is no main function and the return value is returned as the exit code for bic. I haven't implemented parameter passing yet but that shouldn't be too difficult and should be done soon.

[cjwelborn]

I'm trying not to bug you too much with this stuff, especially around the holidays. I'm just excited to get started on the "arbitrary C files" (Issue #29 ) feature and I'm a little stuck on this. It just needs bic's argc and argv translated into your tree objects and inserted where the call to main() is inserted, right? That's the part I'm not too familiar with. I looked into it when I was investigating #31, but I'm not sure what the "complete" tree would look like. I even looked at trees for regular function calls with arguments passed, but I didn't quite see the full picture. I don't know if the tree would contain a copy of the argument strings, or the original pointer/pointers to them.

Any advice would be greatly appreciated.

[cjwelborn]

I've misunderstood what "evaluate a C file and call main" means in bic. I didn't realize that a signature like int main() is all bic needed. I was trying to be explicit and use int main(void) or the standard argc/argv signature, which caused problems with bic. I thought it was some kind of regression. Anyway, I still feel like forwarding arguments from the command line would be a cool feature, but I can see why this isn't as big of a deal as I thought it was. Sorry for the misunderstanding.

[hexagonal-sun]

Hi @cjwelborn ,

Sorry for the delay in replying. Things have been busy over the holidays! :-)

I've been thinking about how to approach the implementation of a scripting mode for bic. I propose the following and would welcome yours and @dzavalishin thoughts.

1. Add a new option for bic -s for script-mode, maybe?
2. The -s option expects an argument, which is the script to be executed by bic.
3. All other arguments that are passed to bic are then interpreted as parameters to be passed to the script. For example the command line invocation: bic -s test.csr arg1 arg2 arg3 would invoke bic, executing test.csr.
4. For the above, argc = 4 and argv = {"test.scr", "arg1" "arg2", "arg3"}.
5. There is no main function in script mode (the topic of this issue), the parser is akin to the REPL. There would be one major difference to script and REPL parser AFAICS, the script should allow the definition of functions.
6. A typical script could look something like:

#!/bin/bic -s

int someInt;

void somefunc()
{
    printf("Hello, world from somefunc!\n");
}

printf("argc: %d\n", argc);
somefunc();
somefunc();

return 0;

7. Some things of note:

• argc and argv are implicitly declared.
• I need to find a way to make the parser ignore the #! at the top the script. Perhaps I could just add a rule to the lexer for this
• A return from the top-level of the script will exit bic with the return's expression as bic's exit code.
• I'm not sure about scoping rules for functions in the script. For example, should someInt be visible inside somefunc, what are your thougts?

[cjwelborn]

No problem, you don't owe anyone anything.

I like all of your points, I just have a question. If there's no return, can we drop into the REPL? This would be like .pystartup files, it just loads a bunch of stuff into the REPL for you to use. This is almost equivalent to #include "myfile.h". If there is a return (or main(), either way) then it exits like you said. This would be for executable scripts that actually return an exit code when they're finished.

argc and argv would be really handy, even if they were only sent to a main() (if one exists). Other languages make them available globally like you're talking about.

Yeh, #! is rejected by gcc and clang as an error, so bic would need to special-case it. The shell sends the entire file to whatever program is specified in the shebang.

As for someInt, I would expect it to be like a file-level declaration for C, and follow almost the same rules (storage would be different for bic I guess, so the rules might not match exactly). But I think it would be visible, and even writable (unless a block-level variable was declared with the same name. I'm not sure how much that complicates things).

I'm just glad you're considering this, seeing how I have a lot of learning to do before I start modifying anything in bic's parser.

@dzavalishin, if you have anything to say about it I'd like to hear it.

[cjwelborn]

This is amazing. I'll check it out today.

[hexagonal-sun]

I've just opened a PR for this (#35) so we can keep track of any outstanding work / bugs. Feel free to post there if you have any feedback, thanks!

[hexagonal-sun]

#35 fixes this issue, closing.