On Jan 9, 8:47 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> I've been working on getting MPIR to compile on Sun CC with --enable-
> cxx. I've fixed the attribute errors by only defining ATTRIBUTE_* when
> __GNUC__ is defined. This fixes lots of build warnings actually,
> though if __GNUC__ is not defined for a compiler which supports
> attributes, then MPIR could potentially be slightly slower (probably
> infinitesimally).
>
> But I'm stuck with the following:
>
> /* this is much the same as gmp_allocated_string in gmp-impl.h
> since gmp-impl.h is not publicly available, I redefine it here
> I use a different name to avoid possible clashes */
> struct __gmp_alloc_cstring
> {
> char *str;
> __gmp_alloc_cstring(char *s) { str = s; }
> ~__gmp_alloc_cstring()
> {
> void (*freefunc) (void *, size_t);
> mp_get_memory_functions (NULL, NULL, &freefunc);
> (*freefunc) (str, std::strlen(str)+1);
> }
>
> };
>
> The Sun CC compiler says:
>
> "../../gmpxx.h", line 1303: Error: Formal argument 3 of type extern
> "C" void(*)(void*,unsigned long)* in call to __gmp_get_memory_functions
> (extern "C" void*(*)(unsigned long)*, extern "C" void*(*)
> (void*,unsigned long,unsigned long)*, extern "C" void(*)
> (void*,unsigned long)*) is being passed void(*)(void*,unsigned long)*.
> "../../gmpxx.h", line 1304: Warning: The variable freefunc has not yet
> been assigned a value.
>
> It took me a while to figure out what the code is trying to do.
> Basically __gmp_free_func is the default function for freeing memory
> allocated by GMP internally. But the user can actually define their
> own memory management functions if they want. There's an interface for
> that, and GMP stores function pointers for the memory managment
> functions the user specifies.
>
> Now if you want to free space allocated by the current memory
> management function, then you better not call __gmp_free_func, as the
> user may have replaced it as the current memory management function.
> Instead you want to call the function the user defined for this
> purpose. So you need to retrieve the function pointer GMP has stored
> for this user defined deallocation function.
>
> That's what the function mp_get_memory_functions does. If you pass it
> a reference to a function pointer as the third argument, it will set
> that function pointer to point to the user defined deallocation
> function.
>
> So in the destructor for this struct, it first declares a function
> pointer, called freefunc. Then it calls mp_get_memory_functions with a
> reference to freefunc as its third argument, and this sets that
> function pointer to be the user defined allocation function. Then it
> actually calls this deallocation function to deallocate the space
> allocated by the initialiser for the struct.
>
> Now the problem is, for some stupid reason, the sun CC thinks
> mp_get_memory_functions doesn't take a reference to a function
> pointer, but a reference to an extern "C" function pointer. I've no
> idea where it gets that from. The function mp_get_memory_functions is
> defines in mp_get_gns.c and its prototype is actually:
>
> void
> mp_get_memory_functions (void *(**alloc_func) (size_t),
> void *(**realloc_func) (void *, size_t, size_t),
> void (**free_func) (void *, size_t))
>
> Does anyone see how to fix this problem?
>
> I'm stumped.
Have you tried putting
#ifdef __cplusplus
extern "C" {
#endif
/*
Code goes here...
*/
#ifdef __cplusplus
}
#endif
Around both the declarations in the header file and also around the C
code?
I am only guessing, but a problem can arise if only one set has extern
"C" changing the interface.
To be really sure I would have to examine the code carefully.
For example, consider:
/* someheader.h: */
#ifdef __cplusplus
extern "C" double myfunc(double);
#endif
...
/* somefile.c: */
#include "someheader.h"
double myfunc(double d)
{
return sin(d) * sqrt(d);
}
Now, since the function definition is not actually bracketed with
extern "C" like the declaration is, then the implementation file will
have a name mangled object and we won't find it if we reference it
using the header file.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
