[CLN-list] CLN patch 1

[Richard B. Kreckel]

Hi!

On 09/10/2010 05:20 AM, Jan private wrote:
> Problem: MSVC creates different symbol names for 'extern "C" uint32
> mulu32_high' when declared inside the cln namespace, and when defined
> inside it. Linking produces "unresolved external symbol" errors.
>
> -----
> Which is allowed by the Standard (specifically, [dcl.link]). However,
> it also says:
>
> "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.
> [Note: because of the one definition rule (3.2), only one definition for
> a function or object with C linkage may appear in the program; that is,
> sucha function or object must not be defined in more than one namespace
> scope."
> -----
>
> Solution: Moved declarations into global namespace and prefixed with
> cln_

Thanks very much for submitting the patch. I see, however, three objections:

1) As it is, it won't work. Recursively greping for mulu32_high and 
those other extern "C" variables under src/base/ reveals that they are 
also used inside the assembler modules. Which is, of course, the entire 
reason why they must have C language linkage! This can should be fixed.

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 [...]. However..."? Do you claim that your 
patch is fixing a problem in CLN or that it is working around a bug in MSVC?

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. 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 bothers 
me. Jan, please don't take this personal but you have to understand my 
position as one outsider who is irritated by a time-consuming continuous 
stream of little patches for compilation with MSVC. I will keep 
accepting patches for whatever compiler as long as they are not too 
disruptive. But I will only do so if the submitter explains what is 
accomplished with it:
* Which compiler version has been used?
* What exactly does the patch fix (a warning, a compile-time error, 
miscompilation)?
* Are more workarounds necessary (compiler options, etc.)?

You are, of course, more than welcome to review your patch under these 
criteria and resubmit it.

Best wishes
    -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>