[Botan-devel] Ambiguity between unsigned int *() and const unsigned int *()

[Jack Lloyd]

On Tue, Jun 12, 2007 at 12:26:12AM +0500, topmop wrote:
> Hello Friends
> 
> I have compiled Botan 1.6.2 in VC++ environment without any problem. And now
> i am trying to use it in Borland C++ Builder.
> 
> When i try to compile a test program in C++ Builder, It gives me below error
> in bigint.h
> 
> ------------------------------------------------------------------------------------------------------------------------------
> Build
>  [C++ Error] bigint.h(61): E2015 Ambiguity between 'MemoryRegion<unsigned
> int>::operator unsigned int *()' and 'MemoryRegion<unsigned int>::operator
> const unsigned int *() const'
>  [C++ Error] bigint.h(83): E2015 Ambiguity between 'MemoryRegion<unsigned
> int>::operator unsigned int *()' and 'MemoryRegion<unsigned int>::operator
> const unsigned int *() const'
>  [C++ Error] bigint.h(84): E2015 Ambiguity between 'MemoryRegion<unsigned
> int>::operator unsigned int *()' and 'MemoryRegion<unsigned int>::operator
> const unsigned int *() const'
> ----------------------------------------------------------------------------------------------------------------------
> 
> These 3 errors are on below 3 lines in bigint.h
> --------return ((n < size()) ? reg[n] : 0);
> -------- word& operator[](u32bit index) { return reg[index]; }
> -------- word operator[](u32bit index) const { return reg[index]; }
> 
> Just for testing, If i take out the reg variable from these lines and use a
> constant value then i dont get any other error.
> 
> Variable reg is of below type.
> SecureVector<word> reg;

It's been a very long time since I even tried using Botan under
C++Builder (which version are you using, BTW?). I think the last was
C++Builder 3 which used the same compiler as Borland C++ 5.0, which
was incredibly buggy. This problem you're seeing is somewhat
surprising, it seems like a lot of code would break if it is unable to
distinguish between const and non-const calls in a scenario like this.

First thought here is to take each of those functions and place them
instead into big_base.cpp and recompile using Visual Studio. In
general you should be able to hide most of the problems (in BigInt and
elsewhere where a memory type is used in an inline function in a
header) that way. On the other hand, I'm not certain with this bug
still existing if it would be possible to really use the library very
easily. Also this would induce a bit more runtime overhead due to the
extra calls, but I don't think anything dramatically bad.

I just took a look at Crypto++, which uses a similar memory block
type, and it disables the const versions of the functions when
__BORLANDC__ is defined. You may want to try that, commenting out
or ifdef'ing out the lines
      operator const T* () const { return buf; }
      const T* begin() const { return buf; }
      const T* end() const { return (buf + size()); }
in secmem.h.

Since simply commenting out those functions is fast, maybe it's worth
a try to see how Borland reacts to that.

> If you will ask for the code i am using, Then as such i am not using
> anything, Just included below files and tried to compile to make sure they
> will work, But apparently i need to change something to make it compatible
> with Borland C++ Compiler?

Seems likely. Hopefully it is relatively straighforward to get it at
least compiling the headers. I'm a bit in the dark here but I'll help
out as much as I can.

> Just to make it clear, I am not compiling Botan itself in Borland C++
> Builder, I am trying to use Botan in C++ Builder.

That's probably a little safer in this case. Ideally Botan could be
compiled entirely under Borland but I'm not sure how likely that is
without major hackery.

-Jack