[CLN-list] msvc patch(es), again

[Alexei Sheplyakov]

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