invalid conversion from typeX** to const typeX**
Hi GCC dev team, I have developed software to parse C(++) code and automatically add const to function arguments (tracing all functions and their references). However, I have encountered an issue with the GCC/VS compilers preventing assignment of typeX** to const typeX**. Considering that const is being automatically added to the code after it is written, there is no danger of the situation occurring that is used to justify this limitation (http://c-faq.com/ansi/constmismatch.html). The const attribute is purely being used to enable programmers to know whether a variable is expected to be modified by the function (no checking of the problematic case above is required). I was wondering; is there any way of working around this design constraint? Thanks for your help. Best Regards, Richard Baxter
Re: invalid conversion from typeX** to const typeX**
On 5 December 2015 at 11:26, Richard Baxter wrote: > Hi GCC dev team, Hi, this is the wrong mailing list for questions seeking help using GCC, please direct any follow-up to the gcc-help mailing list, thanks. > I have developed software to parse C(++) code and automatically add > const to function arguments (tracing all functions and their > references). However, I have encountered an issue with the GCC/VS > compilers preventing assignment of typeX** to const typeX**. > Considering that const is being automatically added to the code after > it is written, there is no danger of the situation occurring that is > used to justify this limitation > (http://c-faq.com/ansi/constmismatch.html). The const attribute is > purely being used to enable programmers to know whether a variable is > expected to be modified by the function (no checking of the > problematic case above is required). I was wondering; is there any way > of working around this design constraint? In C++ you can add the const more thoroughly, changing X** to const X * const *. I don't think that will help for C though.
Re: building gcc with macro support for gdb?
On 12/04/2015 10:32 AM, Tom Tromey wrote: "Martin" == Martin Sebor writes: Martin> To get around these, I end up using info macro to print the Martin> macro definition and using whatever it expands to instead. I Martin> wonder if someone has found a more convenient workaround. For some of these, like the __builtin_offsetof and __null problems, you can add a new "macro define" to gcc's gdbinit.in. In fact I already see __null there, so maybe you don't have the correct add-auto-load-safe-path setting in your ~/.gdbinit. Yes, thanks. The __null problem is fairly easy to work around as you suggested. The one that's more difficult is 18881 where the debugger cannot resolve calls to functions overloaded on the constness of the argument. Do you happen to have a trick for dealing with that one? Martin
Re: building gcc with macro support for gdb?
Martin> The one that's more difficult is 18881 where the debugger cannot Martin> resolve calls to functions overloaded on the constness of the Martin> argument. Do you happen to have a trick for dealing with that Martin> one? Nothing really convenient to use. Sometimes you can get it to do the right thing by using special gdb syntax to pick the correct overload; but of course that's a pain. Tom
