Search

Items tagged with: ifdef


I don't think glibc maintainers care about compatibility considering their constant ABI breakage. New features? Maybe. But as I've said, this might stop some developers from trying out the new shiny things which I consider a good thing. Or if they want to use it, hide it behind #ifdef and supply an alternative. What this does isn't hold back improvement, it forces writing portable code again which everybody forgot in the last 5-10 years. And I'm getting tired of having to package some random new library from a year ago whose version must be from the last 3 months and the Python version must be _latest_ for a piece of software to even consider building itself. Examples: HomeAssistant, Gitea and much more.

This is also mostly a non-issue for open source software where you can always patch it to work on older libc, or make multiple packages if you are the developer. The developer might not want to do it, but maybe the distro maintainers want to which is also fine. And pre-built binaries without source will always suffer since glibc ABI compatibility barely exists.


yeah, that's basically what I found in the curl code left from < 2000. Mostly comments and a few #ifdef/#defines.


I really thought there was a paper titled "C Considered Harmful" but what I can find is this one from 1992:

#ifdef Considered Harmful, or Portability Experience with C News


Authors: Henry Spencer, University of Toronto; Geoff Collyer, Software Tool & Die

Abstract:

We believe that a C programmer's impulse to use #ifdef in an attempt at portability is usually a mistake. Portability is generally the result of advance planning rather than trench warfare involving #ifdef. In the course of developing C News on different systems, we evolved various tactics for dealing with differences among systems without producing a welter of #ifdef at points of difference. We discuss the alternatives to, and occasional proper use of, #ifdef.


usenix.org/conference/usenix-s…

⇧