I would expect a more detailed breakdown of the individual parameters. The type, name, is it a pointer to type, etc. should all be in separate fields

Suggestion noted! I put this together today so there is definitely room for improvement.

Breaking up parameter name, and parameter type into two separate fields will be a good update.

Would there be something that goes the other way? Given a JSON input generates C structs and efficient serialization/deserialization for given input? It could be useful for C++ too but generate classes instead. I'm aware of gsoap which did this for wsdl and generated code for use by SOAP xml clients and servers but not sure if anyone has done this for json

While it's not quite what you want (as the specification language is not JSON---it's more like C declarations), "protobufs" allow you to generate serializers and de-serializers in a number of languages.

http://github.com/google/protobuf

There's thrift, but they have a custom specification with types. It shouldn't be too hard to go from JSON to thrift though.

https://thrift.apache.org/

JSONedit has (experimental) C++ code generator that serializes and deserializes JSON to/from object (default name for class is "Settings" and it uses json-cpp 0.5 as parser and generator): http://tomeko.net/software/JSONedit/cpp_class_generator.php

I've used gcc-xml (apparently has been superseded by another tool now) when I've needed this sort of thing in the past. It has the advantage of being a real C parser rather than a jumble of regexes.

libclang is pretty amazing for that

Python libclang bindings make this kind of task quick work: https://github.com/llvm-mirror/clang/tree/master/bindings/py...

Came to see if this used LLVM for parsing, found node...

LLVM is not for parsing.

But clang can be.

http://clang.llvm.org/docs/Tooling.html libclang is though :)

What's the use case for this?

Seems like it must be to facilitate usage of whatever node's foreign function interface scheme is.

The name is node-ffi and yes, you are correct. Can also be used for automated documentation purposes.

I use something similar to generate API hooks for a large library.

A mess of regexes and splits... yeah, no. You should probably get introduced to the wonderful world of parsers (and compilers):

https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniq...

Please don't be rudely dismissive of new work, even when it seems that someone doesn't know much. The Show HN guidelines specifically emphasize this: https://news.ycombinator.com/showhn.html.

Alright. Sorry, that might have sounded a bit rude, but the intention was pointing OP the right way.

This is a bad name, another cproto library has been in use for over 20 years:

http://invisible-island.net/cproto/cproto.html

You're right, that's kind of why I named the bash command 'proto' instead of 'cproto', but maybe that's not enough. Any suggestions? I'll change it later today.

I should step back some from it being a bad name... It's actually a great name, it just conflicts with an in-use library that does substantially the same thing for another platform.

Is there a convention where the 'node-' prefix is off-limits for any reason? I don't know if it's really any better but if this were 'node-cproto' I wouldn't have commented.

The other option would be to do some word-play name like 'domesticator'.

What happened to descriptive names like 'c2json'?

Nothing, that is also a great name.

I would recommend against using a generic greek prefix for a name of a very specific tool.