Hmm. The wrappers would clearly be inline, but if we want a common
low-level decompress function, we'd also need to introduce the "if (safe &&)"
kind of tests for those differently-defined macros which could impact
performance (for the _unsafe variant only, isn't it). By how much is the
question, and whether we really care to avoid duplicating 50 lines of code
to take that hit on the unsafe function (or vice versa).
> All I will add is that after the amendment I made, the ugliness in my
> patchset is confined to one file now and I still think its the better
> approach to take.
>
> My main concerns with this patch are that:
> * from the security point of view its not tried and tested code
> * I'm not 100% confident in what Nitin has done with the code from a
> buffer overflow/security PoV
> * its not tested on many architectures
> * the performance implications of the rewrite are unknown
Right, it needs testing (for correctness and robustness). But that
shouldn't be too difficult -- Nitin, you could just write up a simple test
module that others can use with your patch to do testing on their
arch's ... the more this gets tested, the better chances it's got.