openssl-sys: declare_std_functions macro

[stbuehler]

Hi,

I have been looking for a way to handle the *mut _ -> *const _ changes in openssl / libressl in a sane way; duplicating all the imports seemed a bad thing.

With proc-macros one could probably invent real crazy syntax, but that would add a lot of dependencies for openssl-sys.

The best thing I could come up with was to define signature schemes (with a single type parameter), which can then be applied using a macro syntax I borrowed from foreign_types. (Macros are not allowed in type position (and name/ident?), so I couldn't get any other "fix this type signature" attempts working).

This will probably add a big merge conflict with the openssl-300 branch, but hopefully makes the process easier in the long run.

Also this changes u8 to c_uchar in a few d2i_* and i2d_ functions; I think this shouldn't break anything (libc::c_uchar should be an alias for u8), but is actually the proper signature.

I checked the imported functions on my local system with my systest-api-items branch, which is based on my ctest out-items branch. After sed -e 's#uint8_t#unsigned char#' the items look the same before and after this PR.

[stbuehler]

Ping :)

I was very happy (and a little bit surprised :) ) how quickly you merged my other -sys PRs, which is why gave this one a try.

I'm not too attached to this PR, but it would be nice to know if you want to consider this or not, i.e. do you think "no way", "perhaps some other time" or "good idea, just not sure about some details"?

I just don't think it makes sense to keep this open much longer; it will quickly result in merge conflicts with other -sys PRs.

[sfackler]

Thanks for the PR! I do think it'd be nice to clean the const/mut stuff up a bit, but I think I'd prefer something with syntax closer to the standard function type. Total strawman, but I could imagine something like this:

extern "C" {
    cfg_const! { #[cfg(ossl102)] // the cfg for the const version
        pub fn some_function(foo: maybe_const(pointee_type), bar: u32);
    }
}

[stbuehler]

I'd like such syntax too, but I think it can only be done with Procedural Macros; if adding dependencies for that sounds fine, I'm happy to give it a try.

I just tried to come up with simple macro examples to show why it can't work, but it compiled.. so I'll try again - perhaps it can be done with macro_rules.

(Splitting arguments is really hard, as you need to match the tokens building a type without using ty. Splitting multiple functions isn't fun either, as they usually end with a type, which again can't be matched using ty. And you can't use ty (afaik) as once it got matched as ty it can't be split into tokens anymore.)

[stbuehler]

Replaced by #1359.