Feature/c api

[ChrisspyB]

No description provided.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 88.70968% with 35 lines in your changes missing coverage. Please review.

Project coverage is 62.67%. Comparing base (5156af4) to head (3597d60).

Files with missing lines	Patch %	Lines
src/metkit/api/metkit_c.cc	83.24%	30 Missing ⚠️
src/metkit/metkit_version.c	25.00%	3 Missing ⚠️
tests/test_c_api.cc	98.36%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop      #57      +/-   ##
===========================================
+ Coverage    61.31%   62.67%   +1.35%     
===========================================
  Files          102      106       +4     
  Lines         6414     6725     +311     
  Branches       611      634      +23     
===========================================
+ Hits          3933     4215     +282     
- Misses        2481     2510      +29     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tbkr]

Like the changes. Code and Documentation was extraordinarily clean. I was a bit nitpicky. Bear with me in case some of my suggestions are not compatible with modern C; it has been a while since I programmed in C ;)

[tbkr]

Here the comment is lacking some words. Do this need to be addressed before merging?

[ChrisspyB]

a todo left for me by me

[Ozaq]

You need an extra test where you use the API and compile the test with a C compiler

[Ozaq]

I think this would make for a nicer API if we could use it like this:

while((res = metkit_paramiterator_next(it))) {
   //...
}

Ofc this would only work if the iteration cannot create errors. But return a nullptr on end of iteration makes for a more natural api imo.

[Ozaq]

Lifetimes of returned values in this iterator differ from the metkit_requestiterator_t iterator. For itself the lifetime is ok (if documented) but a subtle difference in lifetime handling with both types imply symmetrical behavior is a nasty trap. metkit_requestiterator_t result lifetimes exceed the iterator due to the move out of the iterator, while the char* from this iterator dangle as soon as the iterator is freed.

[ChrisspyB]

I initially resolved this by simply getting rid of the paramiterator. But it turns out it's not so straight forward as the C++ marsrequest object does not provide a nice way to iterate over the params so I need to revisit this.

[ChrisspyB]

You need an extra test where you use the API and compile the test with a C compiler

Maybe we should rewrite test_metkit_c.cc in C? For the time being I'll add a simple test that at least uses a C compiler

[ChrisspyB]

Re: error handling, if we're going to do similar across the stack, it might make sense to centralise this somewhere (eckit). All of the caught exceptions are in fact eckit::exceptions

[ChrisspyB]

Note:
Because FDB takes a marsrequest_t (opaque C pointer) from metkit and casts it to a MarsRequest C++ object both libraries must share a compatible C++ ABI. e.g., we'd have problems if metkit is compiled with Intel and FDB with gnu.

This may not be what a user expects when using the C APIs.

[simondsmart]

This doesn't look right.

[ChrisspyB]

Removed the .c configuration