Re: [PATCH olang v1 3/3] cli: add compilation -o option with --save-temps

["Carlos Maniero" <carlos@maniero.me>]

> +typedef enum
> +{
> +    CLI_OPT_DUMP_TOKENS = 1 << 1,
> +    CLI_OPT_OUTPUT = 1 << 2,
> +    CLI_OPT_SAVE_TEMPS = 1 << 3
> +} cli_opt;

nitpick: Any particular reason to avoid using the first bit?

  typedef enum
  {
      CLI_OPT_DUMP_TOKENS = 1 << 0,
      CLI_OPT_OUTPUT = 1 << 1,
      CLI_OPT_SAVE_TEMPS = 1 << 2
  } cli_opt;

> +    string_view_t file_path;

What is the point of making *file_path* a SV? Ever single place it is
used you are accessing it's char pointer directly - *file_path.chars*.
It looks unsafe to just ignore the SV's size, example:
*print_token(opts->file_path.chars, &token)*

> -    char *prog = cli_args_shift(&args);
> +    opts.prog = string_view_from_cstr(cli_args_shift(&args));

nitpick: Is that a standard calling arg0 as prog? I know it was already
there, but taking a fresh look at this name, I find it hard to
understand. WDYT about *opts.compiler_path*, *opts.the_0c_path* or
*opts.this_path*? The point is that, program can be ambiguos here as it
could be both the compiler's program or the program to be compiled.

> +    assert(opts && "args is required");

s/opts/args

> +    string_view_t asm_ext = string_view_from_cstr(".s");
> +    char asm_file[opts->output_bin.size + asm_ext.size + 1];
> +    memcpy(asm_file, opts->output_bin.chars, opts->output_bin.size);
> +    memcpy(asm_file + opts->output_bin.size, asm_ext.chars, asm_ext.size);
> +    asm_file[opts->output_bin.size + asm_ext.size] = 0;

nitpick: you have achieved the same later at this same file using
*sprintf* which I think reads better.

+    char asm_file[opts->output_bin.size + 3];
+    sprintf(asm_file, "" SV_FMT ".s", SV_ARG(opts->output_bin));