Criterion icon indicating copy to clipboard operation
Criterion copied to clipboard

Provide stream & mem helpers

Open Snaipe opened this issue 7 years ago • 1 comments

Using the stream and mem tags to test against files is a bit of a hassle currently. It's not unusable, but it forces users to write boilerplate code, which Criterion tries to avoid in the first place.

This might fall in the domain of "doing too much", but perhaps Criterion should aspire to help users write tests rather than trying its best to do less.

In any case, I think it would be helpful to add two new functions to open memory and stream structures within tests:

void cr_stream_open(const char *url, struct cr_stream *s);
void cr_mem_open(const char *url, struct cr_mem *m);

The good thing with going with URLs is that we can pretty much have a fixed API for I/O testing. I plan to support the following schemes:

  • file://<path>, to fetch local files. This should replace the old file assertion API.
  • fd://<file descriptor>, to open file descriptors. This is mostly here to accept special values for standard streams (stdin, stdout, stderr), but it's a bit inconvenient when you have an int and just want to open a stream from that. I'll have to give it more thought.

Another good thing is that we can check whether libcurl is present on the system, and if it is, route the rest of the schemes through it, so we gain support for a whole lot of protocols. Given that libcurl is by all means omnipresent these days, I think we don't stand to lose anything by doing that integration.

I could also introduce a tcp:// scheme to mean "connect-read-close", but I'm unsure if this warrants the effort at the moment. The good news is that having a generic API means that extending its functionality is rather trivial.

Snaipe avatar May 02 '18 20:05 Snaipe

Alternatively, since the string building facilities are subpar, we could alter the prototype to provide a printf-like behaviour:

void cr_stream_open(struct cr_stream *, const char *url_fmt, ...);
void cr_mem_open(struct cr_mem *m, const char *url_fmt, ...);

That way, we can solve the file-descriptor issue with cr_mem_open(&m, "fd://%d", fd), and we're still addressing the main use-case of fixed URLs by not making things too complicated.

Snaipe avatar May 02 '18 20:05 Snaipe