Re: globals.c->globals.cc

Hi Robert,

Il 12.37 15/12/2002 Robert Collins ha scritto:
>On Sun, 2002-12-15 at 20:33, Guido Serassio wrote:
> > Hi Robert,
>
>
> > There is only a problem:
> >
> > Microsoft Visual Studio apply "name decoration" or "name mangling" to C++
> > object files, so, if all global variables defined in globals.c are
> > referenced from other C++ object files, Squid links fine. But at line 95
> > in MemPool.c:
> >
> > /*
> > * XXX This is a boundary violation between lib and src.. would be good
> > * if it could be solved otherwise, but left for now.
> > */
> > extern time_t squid_curtime;
> >
> > The result is an "squid_curtime unresolved external" error in MemPool.obj
> > when linking.
>
>Hmm, strange that I haven't seen this here, as G++ mangles names too.
>

This is what MSDN says about:

=======
Name Decoration

Usually "name decoration" refers to C++ naming conventions, but it applies to a
number of non-C++ cases as well. The compiler may use the name of a
function, its
parameters, and its return type when calculating a name for a function.
For example, with Visual C++ 2.0, the function name for

    void CALLTYPE test(void)

might come to anything in the following table depending on what the
CALLTYPE is and
whether it is a C or a C++ file.

    Calling convention extern "C" .CPP, .CXX, or .C file

    C naming convention
    (__cdecl) _test ?test@@YAXXZ

    Fastcall naming
    convention (__fastcall) @test@0 ?test@@YIXXZ

    Standard Call naming
    convention (__stdcall) _test@0 ?test@@YGXXZ

CALLTYPEs such as _cdecl, _fastcall, and _stdcall change the naming
conventions for
a function or variable. The 32-bit specific __declspec(<attribute>)
modifier can also
affect the name of the function.

If using C++, be sure to use extern "C" if you are calling a C function
from a C++ program
or if you are calling a function in a C++ from a C program. Extern "C"
forces use of the C
naming convention for global C++ functions; this enables them to be called
from a C program.
Be aware of compiler switches like /Tp or /Tc that force a file to be
compiled as a C (/Tc)
or C++ (/Tp) file regardless of the filename extension, or you may get
different function
names than you expected.

Function prototypes with mismatched parameters can also cause unresolved
external errors.
Many name-decoration schemes incorporate the parameters of a function into
the final
decorated function name. Calling a function with parameter types that do
not match those
in the function definition may also cause this error. This can be a problem
in other
languages, like FORTRAN, which may also add name decoration to a function.
In the following example, the header file with the function prototype does
not match
the function definition; this causes the problem.

Example:

    // Test1.h
    void _stdcall func( char, float );

    // Test1.cpp
    void _stdcall func( char a ){
         a = 'a';
    }

    // Test.cpp
    #include "test1.h"
    void main(void) {
        char var1;
        float var2 = 5;
        func ( var1, var2 ); // Unresolved external error occurs here
    }

There is no set standard for naming conventions between compiler vendors or
even between
different versions of a compiler. Therefore cross-linking object files
compiled with other
compilers or compiler versions may cause unresolved externals.
=========

The big problem comes from the .cc source file extension: for Visual Studio
is not a valid C++
source. With a Registry trick (Q181506) and forcing a /TP on project's
build options all works.
But this seems to force all names of to be "decored", regarding of file
extension, and is not
possible to specify the source type at file level (I LOVE Micro$oft
"features" .... :-) ).

> > Previously I have resolved the issue compiling globals.c as a C source and
> > declaring globals.h as extern "C", but now the squid_curtime problem must
> > be fixed.
>
>Simply continue declaring everything in globals.h as SQUIDCEXTERN, that
>should solve it fine.

I hope this, so after your commit, I will try.

Regards

Guido

>Cheers,
>Rob

-
=======================================================
Serassio Guido
Via Albenga, 11/4 10134 - Torino - ITALY
E-mail: guido.serassio@serassio.it
WWW: http://www.serassio.it
Received on Sun Dec 15 2002 - 05:06:31 MST