Split into lib.rs and main.rs

[syxolk]

cargo-fuzz needs a library to link with.

[syxolk]

Proposed header file for an imaginary libindentex.so:

/// Opaque options struct
struct indentex_transpile_options;

/// Create a new transpile options object
// Default values:
// - flatten_output = false
// - prepend_do_not_edit_notice = true
struct indentex_transpile_options* indentex_transpile_options_new();

/// Delete previously created transpile options object
void indentex_transpile_options_delete(struct indentex_transpile_options* options);

/// Set or get flatten_output option
void indentex_transpile_options_set_flatten_output(struct indentex_transpile_options* options, int val);
int indentex_transpile_options_get_flatten_output(const struct indentex_transpile_options* options);

/// Set or get flatten_output option
void indentex_transpile_options_set_prepend_do_not_edit_notice(struct indentex_transpile_options* options, int val);
int indentex_transpile_options_get_prepend_do_not_edit_notice(const struct indentex_transpile_options* options);

/// Transpile a given indentex file
int indentex_transpile_file(const char *path);
int indentex_transpile_file_options(const char *path, const struct indentex_transpile_options* options);

/// Transpile a given indentex string
int indentex_transpile(const char* input, char* output, size_t output_len);
int indentex_transpile_options(const char* input, char* output, size_t output_len, const struct indentex_transpile_options* options);

Update: This is the most ABI-stable api I was able to come up with. It's probably overkill. We could just use a simple bitset for our current set of transpile options.

[mp4096]

Hm... Stupid question: Why is ABI stability important? I could imagine that it is important if I were to call indentex.so from other languages, e.g. Python. But do we need it for cargo-fuzz?

Another question: How would you implement this interface? Would you just use 'normal' Rust functions as usual and provide some very thin extern C wrappers?

[syxolk]

Why is ABI stability important?

It's not really needed but probably useful for the live demo on the website (Tornado + libindentex serverside or WASM clientside). For cargo-fuzz we don't need a C-API.

How would you implement this interface?

We would wrap transpile and transpile_file in rust using #[no_mangle] extern "C".

[mp4096]

Why is ABI stability important?

It's not really needed but probably useful for the live demo on the website (Tornado + libindentex serverside or WASM clientside). For cargo-fuzz we don't a C-API.

Ah, I see. I dunno. I'm all for a live demo on the website, but I thought about having a completely static website and calling an AWS Lambda function or a Heroku app for transpilation.

Another possibility would be using Rocket.rs, but it's still kind of unstable.

In general, I am not eager having a dynamical website since I don't have time to maintain it.

[syxolk]

I'm all for a live demo on the website, but I thought about having a completely static website and calling an AWS Lambda function or a Heroku app for transpilation.

Yeah, makes sense. You still need a library that you can call from any language that is supported on lambda.

I am not eager having a dynamical website since I don't have time to maintain it.

That's why I tried the Rust->WASM stuff. If it works you won't need any server-side stuff.

[mp4096]

You still need a library that you can call from any language that is supported on lambda.

You're right! Forgot about that. In my mind I clinged to a magic connection between Python and Rust via filesystem :rofl: or pipes.

[mp4096]

BTW, how you determine input length here, just by looking for \0? Isn't it better (O(1) instead of O(n)) to supply the input length as well?

int indentex_transpile(const char* input, char* output, size_t output_len);

Also see the docs for from_raw_parts

[syxolk]

Isn't it better (O(1) instead of O(n)) to supply the input length as well?

Depends on the API design and the usage of your string. std::ffi::CStr::from_ptr:

This operation is intended to be a 0-cost cast but it is currently implemented with an up-front calculation of the length of the string. This is not guaranteed to always be the case.

I simplified it now to this:

#define INDENTEX_FLAGS_FLATTEN_OUTPUT 1
#define INDENTEX_FLAGS_DISABLE_DO_NOT_EDIT 2

int indentex_transpile_file(const char *path);
int indentex_transpile_file_flags(const char *path, int flags);

int indentex_transpile(const void *input, size_t input_len,
        void *output, size_t output_len);
int indentex_transpile_flags(const void *input, size_t input_len,
        void *output, size_t output_len, int flags);

The return codes (error codes) are not yet specified.

[syxolk]

Ok, this API is not sufficient once you want to get detailed error messages. 😞

It's probably a lot easier to just implement some command line flags for piping in/out and writing error messages to stderr.

[mp4096]

I see. Let's go for piping, then.