On Fri, Jun 15, 2012 at 11:06 AM, Ian Lance Taylor <i...@google.com> wrote: > Richard Guenther <richard.guent...@gmail.com> writes: > >> Ian - you added this include in rev. 167764, I don't think that was "proper". >> But I'm not sure wrapping a system.h include inside extern "C" from a C++ >> plugin is proper either ... > > I did commit 167764 but I didn't write it. It's from > > http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02567.html > http://gcc.gnu.org/PR46650 > > The patch is there because system.h poisons strerror. Clearly we have > to #include <string.h> before poisoning strerror. And we do. But when > we #include C++ headers, some of the C++ headers #include <cstring>. So > system.h needs to do that also. > > I think there is no question that as long as system.h poisons strerror, > we need to arrange to #include both <string.h> and <cstring> before that > poisoning, and that the natural way to ensure that is to #include both > in <system.h>. And that is what we do today. > > I don't really know what the right solution is here, because I don't > know how we feel about wrapping #include "system.h" in extern "C". A > simple workaround is to #include <cstring> before the #include > "system.h". Or the OP's patch using extern "C++" is a simple workaround > within system.h. > > Or maybe we simply drop the poison of strerror, and then system.h > doesn't need to #include <cstring> anyhow.
As long as we don't control <string.h> and <cstring>, we can't put them in a language linkage specification. What we can do is what I suggested in my last message: just give the language specification to the declarations that matter in gcc/system.h. -- Gaby
