|
|
|
|
|
|
by asveikau
2161 days ago
|
|
|
I think the multiplatform support is an interesting criticism but misunderstood. I happened to be reading some OpenSSL code around the time of heartbleed and statically linking some of it in a project. I found a lot of the portability ifdefs were poorly done even for the standards of the 90s. It wasn't portability itself that was the issue, it was actual quality and in many cases the wrong abstractions in place. One example that sticks out in my memory... There was a logger that had a Win32 ifdef. If you ran on Win32 it fed log messages directly to MessageBox(). Unless it detected the current process was an NT service, in that case it used another logging mechanism without asking. It wasn't actually "windows portability" or "windows support". The whole thing wasn't appropriate for a library. It could have had a mechanism to give the log lines to the application as a C string and be done with it. Instead, it was mixing of library layer stuff and application layer stuff, or just ordinary library bloat. The other huge example I recall was compliance with older configurations that were pre-C99. C99 is much more universal now vs 20 years ago, although there are a few things Microsoft still doesn't support. But again, a bunch of these things seemed to be handled with ifdefs at the call site, rather than put in a proper compatibility layer that only an older configuration gets. It does seem that in the years since then, cruft has been removed not only in forks but also in the upstream project. |
|
|
Also as someone that has a code base that targets a dozen different pieces of hardware ifdef madness is a strong indication that your program architexture is broken. Sometimes it's unavoidable but you should think of ifdef's as another name for FIXME.