Renaming all symbols in libmp(3)

Christoph Mallon christoph.mallon at gmx.de
Thu Feb 26 13:02:32 PST 2009


Christoph Mallon schrieb:
> David Schultz schrieb:
>> On Thu, Feb 26, 2009, Ed Schouten wrote:
>>> One of the reasons why we can't compile the base system yet, is because
>>> some applications in the base system (keyserv, newkey, chkey, libtelnet)
>>> won't compile, because a library they depend (libmp)on has a function
>>> called pow(). By default, LLVM has a built-in prototype of pow(),
>>> similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The
>>> manual page also mentions this issue.
>>
>> I think most apps that used to use libmp have transitioned to
>> libgmp, so I don't have much of an opinion on this change...
>>
>> However, if the compiler as a builtin for the math.h-style pow()
>> function, and the builtin causes it to choke even when math.h
>> isn't #included, that's a bug in the compiler. The people who are
>> proposing that we make the base system LLVM-compatible should be
>> more forceful in insisting that LLVM be fixed. ;-) What do the LLVM
>> folks propose to do about all the (perfectly legal) programs out
>> there that have a variable called 'exp'?
> 
> No, it's invalid code to have a function named pow() in a hosted 
> environment which is not /The/ pow().
> Having a *local* variable named exp is fine, because this declaration 
> shadows the function. A *global* variable on the other hand is not allowed.

Just a hint, why you really mustn't use global names which are reserved 
by the standard:

double pow(double x, double y)
{
   abort();
}

int main(void)
{
   printf("%f\n", pow(10., 2.));
   return 0;
}


%gcc -w bla.c
%./a.out
100.000000
%

Yes, GCC does that and it's perfectly valid.


More information about the freebsd-hackers mailing list