Hello, On Mon, Feb 07, 2011 at 09:25:13AM +0100, Richard B. Kreckel wrote:
2) My reading of this section is that MSVC has a bug: "Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object." What do you mean when you write "Which is allowed by the standard [...].
Having an extern "C" variable/function in the namespace scope is allowed by the standard. However, there are some limitations which effectively deny the purpose of namespaces. That is, according to [dcl.link] "At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object." For instance, in the code below namespace A { extern "C" int f(); } namespace B { extern "C" void f(); } A::f() and B::f() actually refer to the same function! In my opinion it's very confusing, and we'd better avoid using extern "C" functions (and variables) in the namespace scope.
However..."? Do you claim that your patch is fixing a problem in CLN or that it is working around a bug in MSVC?
The patch works around msvc bug, *and* it helps CLN to avoid potential problems. The name `mulu32_high' is generic enough, and if someone ever writes namespace mylibrary { extern "C" unsigned int mulu32_high; } we'll get an obscure bug.
3) I don't have access to MSVC. We've received many patches for CLN (and GiNaC, too) and applied most of them. Yet, it is still unclear to me what the status under MSVC is. Since patches keep coming in, I suppose that things are still not fully working.
I don't think this conclusion is correct. GCC-related patches keep coming in, too (to name few, commit 3c3275884, 44fa38df2, 352547eac, and so on). This doesn't mean that things are still not fully working, does it?
The way I see it is this: There are two major free compilers out there (GCC and Clang) that don't have any problem compiling the current git HEAD of both packages and it still looks like we are pampering around problems in an expensive piece of crap by a really big and annoying software manufacturer.
This is not completely correct: many (most?) of msvc-related patches fix buggy and/or nonportable code, such as incorrect iterator usage (incrementing end()), access beyond the vector limits, etc. Best regards, Alexei