Is it time for a libc_fixes library yet?

[Ken Cunningham]

> 
> Your library offers multiple functions... getline, strndup, etc.
> 
> What happens if a software package provides, for example, a compatibility implementation of getline but not strndup? Can your library be used in this case or will that also "cause trouble", as you put it above?


Very good point. So far, all the ports I've tested either assume the 2008 standard, or don't. So it has never happened yet. But in such as case, at least for now, we'd have to go back to the manual patching method we've used over time.

We could put #defines around each function, and specifically request them with env variables or something -- but that gets very confusing I would argue, and gets away from the thrust of this.

I would say this solves the issue for >90% of the situations so far. And if so, that's a lot less work. So better, I hope, but not perfect.


Perfect would be if I just wrote it into the clang code directly. I am almost to the point where I could do that, actually. I know where it would go, I think.


> 
> 
> I see the port and a portgroup have been added to MacPorts. I would like to request that each port that adopts this port/portgroup also add a comment explaining upstream's stance on the issue. For example, a link to the upstream bug report.
> 

You are 100% correct that upstream should do this, and this is far better. I should say over the past year I can't think of a single instance where I saw that upstream actually did add one of these old functions, though. Maybe you know of some cases.

autotools is an ugly thing to learn beyond the defaults. And I still don't see how to do this kind of thing by default with cmake.

Thanks!

Ken