Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!raeburn
From: raeburn@athena.mit.edu (Ken Raeburn)
Newsgroups: comp.lang.c++
Subject: Re: cfront name mangling
Keywords: names, frustration
Message-ID: <1990Jul13.151612.14165@athena.mit.edu>
Date: 13 Jul 90 15:16:12 GMT
References: <140@emtek.UUCP>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: Massachusetts Institute of Technology
Lines: 34

In article <140@emtek.UUCP> matt@emtek.UUCP (Matt Meola) writes:
>
>Does anyone know why cfront mangles the name catch_sig(int) into
>catch_sig__FiPFve_v ?  My code compiles fine, but the loader (ld)
>complains about not knowing about the name catch_sig__FiPFve_v.
>Any ideas?

This is done to permit function overloading based on argument types.
The ugly string tacked on the end is a compact description of the
argument list that the function accepts.  Hence, if you have

	int min (int, int)
	double min (double, double)

then two different functions names will be used at the
C/assembler/linker levels, both starting with "min__" but ending with
different strings.

If you are trying to link to C code (which I presume is the case since
you say catch_sig__FiPFve_v isn't known) try using

	extern "C" catch_sig (int);

to tell cfront that the function should be given C linkage (i.e., no
encoding of the argument types in the name).  (Um, I'm assuming you're
using cfront 2.0 here....)

If catch_sig(int) is a C++ function, make sure that your definition
and declarations agree on what the argument list looks like.
--
~~
~~ Ken Raeburn / raeburn@athena.mit.edu
~~ systems programmer
~~ MIT Project Athena