@SolidWallOfCode > My view is every reduction of using the C preprocessor is a good thing and > therefore a utility that enables that in many cases is valuable, even if it > doesn't cover all such uses.
Partially agreed. It doesn't have to cover all use cases. I wanted to point out the inconsistency issue. > As for the inconsistency, that's only a style issue. You could just as easily > wrap the #ifdef code in a wrapper function. I was talking about a case that we cannot easily provide a wrapper. When I tried to support BoringSSL on QUIC code, I found a case that we cannot simply replace OpenSSL function calls. I haven't figured out the case, but I would probably need to call BoringSSL functions from different places and the logics for each libraries would be pretty different. I don't think this case has to be covered by this utility but it suggests that making TS_SSL_x doesn't work every cases, and I think ifdef is suitable in this case. So, this would lead the same issue as `ink_strlcmp`. One reason I don't like making this kind of wrappers on lower layer is that I need to check whether wrapper X for function x is provided before using function x. This is a reason I didn't create `ink_be64toh` (See ink_endian.h). I can live with it but I wanted to know how many places (and how much) we can improve with this. > Handling the multiple feature case turns out to be easy in most cases as > well. Because of the abuse of the comma operator in the decltype, there's no > limit on how many expressions can be checked in one case. If three are > needed, all three can be checked in the same case. Alright, sounds like it's possible. But again, I want to see how much it makes code readable and beautiful. Can you make separate PRs that use this utility so that I can see the improvements? [ Full content available at: https://github.com/apache/trafficserver/pull/4140 ] This message was relayed via gitbox.apache.org for [email protected]
