This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] Fix / clean-up config vs crosses (2/n)


Mark Mitchell wrote:
Actually, I don't know much about them, except from a very high-level perspective. I could go dive into it, of course, but for me this is more theory than practice, I'm afraid. There are so many systems out there that I just think it pays to be paranoid.

Concretely, I have no evidence of a system which puts writev in headers without guaranteeing it appears in the C library, but I can imagine it.
Sure. On the other hand, I'm not sure it pays to be paranoid ;) I mean, AFAIK, libstdc++ doesn't work well on many embedded systems for many other reasons besides this one. If we can be reasonably sure that on the widespread targets the issue with declared-not-used doesn't exist for some functions, we could, in my opinion, complete a nice clean-up of these cross-configury things, and leave special needs to command-line options - as you mentioned - or hard coded values, which would be implemented and contributed by the target maintainers actually caring about those systems on a case by case basis. That last point leads me to a related observation: often, unfortunately, maintainers of targets potentially benefiting from some changes do not exist, or do not care; in that case, sheer paranoia without any serious deep knowledge of the targets doesn't seem the right attitude for a general maintainer of the library, in particular when it blocks improvements which would clearly benefit a large number of users, whose targets are well known and maintained.

Well, I have also a polemic point for people (not you, Mark, to be 100% clear!) using too easily the word "broken" (which, literally translated in italian sound really bad and impolite, maybe in English is different) without a constructive proposal and without clearly showing understanding of the existing trade-offs, but I will not insist...

Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]