Show HN: C programming language extension: Cedro pre-processor (sentido-labs.com)

This feels very niche. Typing the \ at the end of multi-line macros is something many editors help with (and forgotten \s are visible in syntax hilighting.) Binary inclusion is frequently just a small build script. Deferred resource release is already available as a GCC/clang extension, so it's only for less capable compilers as you say yourself.

That leaves the @ operator… which seems useful for specific cases (e.g. graphics rendering), but I can honestly say I don't really feel a need for that in the codebases I worked with.

But. Let me offer some suggestions for extensions! :)

An improved preprocessor would be massively useful if it had features like:

- enumerating struct members in preprocessor macros (something like:)

  #define MACRO2(typename, fieldname, arg1, arg2) ... arg1 arg2 ...
  #define MACRO(typename, arg1, arg2) something { #each-member(MACRO2, typename, arg1, arg2) }

  struct bla {
    int a, b;
  }

  MACRO(struct bla, x, y)
  /* => something { MACRO2(struct bla, a, x, y) MACRO2(struct bla, b, x, y) } */

- same, for function parameters

- and last but not least, macros consuming { } blocks, e.g.

  #define MACRO(...)#{name} something something #{name} something #{name}
  
  MACRO(1,2,3) {
    this block is consumed by the macro and placed in 2nd and 3rd #{name} (first one just signals the macro consumes a {} block
  }

...oh and, almost forgot, "extensible" macros:

  #define MACRO(...) abc

  #ifdef MACRO
  #extend MACRO(...) def MACRO(...) ghi
  #else
  #define MACRO(...) def stub ghi
  #endif

(also, macros that can define other macros. Like _Pragma() => #pragma, _Define() => #define)

Your comment reminded me of the early days when I learned C in the mid 1980s, and I complained about the lack of a string type (which I had been used to from Pascal, Modula-2 and even BASIC), people said one should have the freedom to implement them as 0-terminated strings or using length and a char array, or even in other ways.

To me that has always been a lame excuse for a poor standard library. You can always build your own, even if the standard library has a solution that works for 99% of cases - and that makes 99% of code more readable to 100% of people.

I love C (let's not get into a C++ rant here..) so this is just a comment about the culture, like the parent post. The fact that people who don't like to re-invent the wheel have not stuck with C, and maybe gone to join the Perl, Python, Java... communities made this issue worse over the years.

In theory, this could still be done now (e.g. a standard build system), but I think most "systems language" innovation action now firmly happens in the Rust camp (which may be a good thing, because the world needs more safe code).

  [1]: https://scattered-thoughts.net/writing/against-sql/#innovation-at-the-implementation-level-is-gated

Communities with opinions and build systems and style guides showed up, and weren't that hard to find.

https://www.gnu.org/prep/standards/html_node/index.html

> I wish binary inclusion was provided by more languages or build systems. For small files it's a very suitable alternative to the difficulties of packaging resources when distributing an application or library.

When it occasionally comes up as a need, I use the bintosrc command available at https://github.com/jochenleidner/ltools

Nice to meet you!

Thanks for the nice words, my program is much more modest than cmacro :-)

Yes, I think that the transform you describe would require the processor to know about types, which is something I avoided here. I experimented early with writing a function that would track the types of things and enable smarter macros, but it became obvious that it was going to be a choice between writing a full compiler frontend and a hacky thing that worked only in trivial cases, so I discarded it.

The decision was to keep it as a naïve macro processor, just with a minimum understanding of C syntax, and leave out anything that requires taking into account the semantics. I have other macros that do things like expanding «obj[a..b]» to «(Slice){.start_p=&obj[a], .end_p=&obj[b] }» but they are not worth it, because to work smoothly they would need to know the type of «obj». If absolutely needed, I think that «_Generic» could be used here but it starts complicating things beyond the point of diminishing returns.

Formally this is called a pipeline operator and can be used like this:

    type_t value = allocate();
    operate(value) |> operate |> destroy;

Functional languages like OCaml, F#, and Haskell have it built in.

I am a very weak C programmer, but one thing I find myself doing a fair bit is wrapping the intermediate data from sequences of operations like this into a single structure representing the whole task or unit of work or whatever. That structure then has a single 'valid' and/or 'error' field that each step checks to see if it should actually proceed, and if so, it will fill its field in the structure, and the next step will pick up from there.

That way you get to write something like:

    typedef struct cookie_batch {
      bool valid;
      bool baked;
      unsigned short ingredient_count;
      char **ingredients;
    } cookie_batch;

    .
    .
    .

    void bake(cookie_batch *batch) {
      if(!batch->valid) return;
      batch->baked = true;
    }

    .
    .
    .

    cookie_batch batch = { .valid = true };
    add_ingredients(&batch);
    bake(&batch);
    serve(&batch);
    cleanup(&batch);

So you don't need any complex error handling in client code.

Not sure about the example semantics, but with MyDef (https://github.com/hzhou/MyDef), it is trivial --

    $call value_ops, val, operate, operate

    subcode: value_ops(v, @ops)
        type_t $(v) = allocate();
        $(for:op in $(ops))
            type_t tmp$(_i) = operate($(v));
            $(set-1:v=tmp$(_i))
        destroy($(v))

MyDef is a general purpose preprocessor.

EDIT: maybe this is more fit what was intended

    type_t var;
    $(for:op in allocate, operate, operate, destroy)
         var = $(op)(var);

I’m trying to see if this could be done without writing your own macro in C (put it inside «src/macros/», list it in «src/macros.h»), but I first need to understand it correctly.

Since «ANSELBbits.ANSB3 = 0» sets the write to digital, would it not belong in «digitalWrite()» instead?

Would it work if the generated code was like this?

    TRISBbits.TRISB3 = 0; // RB3 is output (pinMode)
    ANSELBbits.ANSB3 = 0; // RB3 is digital (digitalWrite)
    LATBbits.LATB3 = 1; // RB3 is set to high (digitalWrite)

EDIT: Assuming I got the meaning right, you can get quite close with standard C macros, but since I’m here demoing Cedro we could as well use it:

    #pragma Cedro 1.0

    enum { OUTPUT = 0, INPUT = 1 };

    #define { pinMode(REGISTER, DIRECTION)
    TRISBbits.TRIS##REGISTER = DIRECTION
    #define }

    enum { LOW = 0, HIGH = 1, DIGITAL = 0, ANALOG = 1 };

    #define { digitalWrite(REGISTER, LEVEL)
    ANSELBbits.ANS##REGISTER = DIGITAL;
    LATBbits.LAT##REGISTER = LEVEL
    #define }

    #define { analogWrite(REGISTER, LEVEL)
    ANSELBbits.ANS##REGISTER = ANALOG;
    LATBbits.LAT##REGISTER = LEVEL;
    #define }

    int main(void)
    {
      TRISBbits.TRISB3 = 0; // RB3 is output (pinMode)
      ANSELBbits.ANSB3 = 0; // RB3 is digital (digitalWrite)
      LATBbits.LATB3 = 1; // RB3 is set to high (digitalWrite)
    
      pinMode(B3, OUTPUT);
      digitalWrite(B3, HIGH);
    }

If you put that in a file («regtest.c») and run it through Cedro and the standard pre-processor, you get this:

    $ ../bin/cedrocc -E regtest.c
    # 1 "<stdin>"
    # 1 "<built-in>"
    # 1 "<command-line>"
    # 31 "<command-line>"
    # 1 "/usr/include/stdc-predef.h" 1 3 4
    # 32 "<command-line>" 2
    # 1 "<stdin>"
    # 3 "regtest.c"
    enum { OUTPUT = 0, INPUT = 0 };
    # 9 "regtest.c"
    enum { LOW = 0, HIGH = 1, DIGITAL = 0, ANALOG = 0 };
    # 16 "regtest.c"
    # 21 "regtest.c"
    int main(void)
    {
      TRISBbits.TRISB3 = 0;
      ANSELBbits.ANSB3 = 0;
      LATBbits.LATB3 = 1;
    
      TRISBbits.TRISB3 = OUTPUT;
      ANSELBbits.ANSB3 = DIGITAL; LATBbits.LATB3 = HIGH;
    }

The only part that uses Cedro is the block #defines for «pinMode()» and «digitalWrite()».

EDIT2: I suspect that what you really need is a «macro» that checks that the register has been last set to the correct direction (INPUT/OUTPUT) and mode (DIGITAL/ANALOG) before calling the «…Write()»/«…Read()» functions. For instance, if B3 was last set to ANALOG and you call «digitalWrite(B3, …)», it would insert «ANSELBbits.ANSB3 = DIGITAL», but not if it was last set to DIGITAL, and so on for all function variants: «digitalWrite()», «digitalRead()», «analogWrite()», «analogRead()».

You could write such a function in «src/macros/pic32.c», list it in «src/macros.h», and Cedro would run it.

> But as I type this comment I realize that other syntax parsing tools like IDEs would be happier if the unprocessed code is still valid C.

Yes, that’s the reason. The code is still close enough to standard C to work well with Emacs for instance. It would be a deal breaker for me to require a special editing mode.

Like the article mentioned, GCC, clang & icc all have the __cleanup__ attribute that can call a destructor for when a value moves out of scope. (And works pretty much how it would in C++). MVSC is really the only one missing it of the major compilers, but it doesn't implement half the actual standard anyways.

__cleanup__ might be a C extension, but it's pretty widely supported. If you really wanted to have it be a code block instead of a function, in plain C, then you could possibly also use clang or GCC's lambda-ish extensions.