For whatever reason (compiler or header bugs), at least one commonly-used
linux system (namely mine) chokes on our definitions and uses of the "HZ" symbol in crypto/tmdiff.[ch] and apps/speed.c as a "bad function cast" (when in fact there is no function casting involved at all). In both cases, it is easily worked around by not defining a cast into the macro and jiggling the expressions slightly. In addition - this highlights some cruft in openssl that needs sorting out. The tmdiff.h header is exported as part of the openssl API despite the fact that it is ugly as the driven sludge and not used anywhere in the library, applications, or utilities. More weird still, almost identical code exists in apps/speed.c though it looks to be slightly tweaked - so either tmdiff should be updated and used by speed.c, or it should be dumped because it's obviously not useful enough. Rather than removing it for now, I've changed the API for tmdiff to at least make sense. This involves taking the object type (MS_TM) from the implementation and using it in the header rather than using "char *" in the API and casting mercilessly in the code (ugh). If someone doesn't like "MS_TM" and the "ms_time_***" naming, by all means change it. This should be a harmless improvement, because the existing API is clearly not very useful (eg. we reimplement it rather than using it in our own utils). However, someone still needs to take a hack at consolidating speed.c and tmdiff.[ch] somehow.
Showing
想要评论请 注册 或 登录