This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end


On Wed, Jun 9, 2010 at 7:11 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 9 June 2010 14:08, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> On Wed, Jun 9, 2010 at 6:53 AM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>> On 9 June 2010 13:33, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>>>> On Wed, Jun 9, 2010 at 4:53 AM, Manuel López-Ibáñez
>>>> <lopezibanez@gmail.com> wrote:
>>>>> On 8 June 2010 18:14, Jason Merrill <jason@redhat.com> wrote:
>>>>>> On 06/08/2010 10:43 AM, Manuel López-Ibáñez wrote:
>>>>>>>
>>>>>>> On 8 June 2010 16:06, Jason Merrill<jason@redhat.com> ?wrote:
>>>>>>
>>>>>>>> The error message is unclear, but the issue is that converting from
>>>>>>>> char**
>>>>>>>> to char const** is unsafe, while converting to char const*const* is safe.
>>>>>>>
>>>>>>> What does it mean unsafe in this context? I could produce a patch that
>>>>>>> changes the message but I would like to be sure what to say.
>>>>>>>
>>>>>>> semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
>>>>>>> **' to 'const char **' is unsafe [-Werror=cast-qual]
>>>>>> Explanation from the C++ standard (4.4 [conv.qual]):
>>>>>>
>>>>>> [ Note: if a program could assign a pointer of type T** to a pointer of type
>>>>>> const T** (that is, if line #1 below were allowed), a program could
>>>>>> inadvertently modify a const object (as it is done on line #2). For example,
>>>>>>
>>>>>> ?int main() {
>>>>>> ? ?const char c = ’c’;
>>>>>> ? ?char* pc;
>>>>>> ? ?const char** pcc = &pc;// #1: not allowed
>>>>>> ? ?*pcc = &c;
>>>>>> ? ?*pc = ’C’; // #2: modifies a const object
>>>>>> ?}
>>>>>> --end note ]
>>>>>
>>>>> So what do you think about the following message:
>>>>>
>>>>> error: new ‘const’ qualifier in cast from 'char **' to 'const char **'
>>>>> is unsafe [-Werror=cast-qual]
>>>>> note: to be safe all intermediate pointers must be equally qualified
>>>>
>>>> that is OK; but I find the leading 'new' hard to parse. ? Please, just
>>>> remove it.
>>>>
>>>
>>> Anyway, this is the C FE.
>>
>> Yes, I know.
>>
>>> The C++ FE gives the following:
>>>
>>> test.C:4:23: warning: invalid conversion from ‘char**’ to ‘const
>>> char**’ [-fpermissive]
>>>
>>> but the code is too intricate to give a clearer error in the case of
>>> C++ or to factor out the common check.
>>
>> Removing the leading 'new' does not require any of that.
>
> Of course, it was a just a comment since consistency between C and C++
> is a goal, so we should always check for low hanging-fruit. Not this
> case unfortunately.
>
> I am bootstrapping this:
>
> Index: gcc/c-typeck.c
> ===================================================================
> --- gcc/c-typeck.c ? ? ?(revision 160384)
> +++ gcc/c-typeck.c ? ? ?(working copy)
> @@ -4493,9 +4493,12 @@
> ? ? ? ? ?&& !is_const)
> ? ? ? ?{
> ? ? ? ? ?int added = TYPE_QUALS (in_type) &~ TYPE_QUALS (in_otype);
> - ? ? ? ? warning (OPT_Wcast_qual,
> - ? ? ? ? ? ? ? ? ?("new %qv qualifier in middle of multi-level non-const cast "
> - ? ? ? ? ? ? ? ? ? "is unsafe"), added);
> + ? ? ? ? if (warning_at (input_location, OPT_Wcast_qual,
> + ? ? ? ? ? ? ? ? ? ? ? ? ?"%qv qualifier in cast from %qT to %qT is unsafe",
> + ? ? ? ? ? ? ? ? ? ? ? ? ?added, in_type, in_otype))
> + ? ? ? ? ? ? ?inform (input_location,
> + ? ? ? ? ? ? ? ? ? ? ?G_("to be safe all intermediate pointers"
> + ? ? ? ? ? ? ? ? ? ? ? ? " must be equally qualified"));
> ? ? ? ? ?break;
> ? ? ? ?}
> ? ? ? if (is_const)
>
> There will be some testcases that need adjusting.
>

OK, thanks!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]