[Bug debug/20230] New: GCC generates non-compliant warnings for qualifier promotion

[Bug debug/20230] New: GCC generates non-compliant warnings for qualifier promotion

[kmk at ssl dot org]

When compiling code with GCC that involves passing an unqualified object to a
function that advertises certain qualification guarantees, unsuppressible
warnings are generated about passing "incompatible types."

That these types are formally incompatible under the standard is not in
question. It is, however, irrelevant. While I do not possess the ISO document
(C++ is my native tongue, and G++ does not exhibit this flaw), I was able to
download draft n843 from the Internet, and it explicitly states:

"For any qualifier q, a pointer to a non-q-qualified type may be converted to a
pointer to the q-qualified version of the type; the values stored in the
original and converted pointers shall compare equal." [section 6.3.2.3, paragraph 2]

The intention of this provision is quite clear: functions should be able to
advertise qualification guarantees that are more strict than the actual
qualifications of any call parameters supplied to the function when it is
called. By generating unsuppressible warnings for explicitly-permitted qualifier
promotions, GCC makes it impossible to avoid warnings when compiling code that
is completely in compliance with the standard. This greatly complicates the
maintenance of warnings-free code in complex development environments and
critically reduces the utility of the const keyword.

Test case:
----------------------

void safe_function(const char *const *s) { }

int main(void) {

  char *mystrings[2] = { "First string", "Second string" };

// This call warns, but should not:
  safe_function(mystrings);

}

----------------------
Compiler output:

Using built-in specs.
Configured with: ./configure --prefix=/usr --host=i386-just-dragonflybsd
Thread model: posix
gcc version 3.4.3 [DragonFly] (propolice, visibility)
 /usr/libexec/gcc34/cc1 -E -quiet -v -iprefix
/usr/libexec/gcc34/../gcc34//3.4.1/ bug2.c -march=pentium3 -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts
-Winline -Wnested-externs -Wredundant-decls -O -o bug2.i
ignoring nonexistent directory "/usr/libexec/gcc34/../gcc34//3.4.1/include"
ignoring nonexistent directory "/usr/libexec/gcc34/../gcc34//3.4.1/libdata/gcc34"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /usr/libdata/gcc34
End of search list.
 /usr/libexec/gcc34/cc1 -fpreprocessed bug2.i -quiet -dumpbase bug2.c
-march=pentium3 -auxbase bug2 -O -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wall -W
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts
-Winline -Wnested-externs -Wredundant-decls -version -o bug2.s
GNU C version 3.4.3 (i386-just-dragonflybsd)
        compiled by GNU C version 2.95.4 20020320 [DragonFly].
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
bug2.c:2: warning: no previous prototype for 'safe_function'
bug2.c:2: warning: unused parameter 's'
bug2.c: In function `main':
bug2.c:6: warning: initialization discards qualifiers from pointer target type
bug2.c:6: warning: initialization discards qualifiers from pointer target type
bug2.c:9: warning: passing arg 1 of `safe_function' from incompatible pointer type
bug2.c:11: warning: control reaches end of non-void function
 as -o bug2.o bug2.s
 ld -V -dynamic-linker /usr/libexec/ld-elf.so.1 -o bug2 /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib/gcc34 bug2.o -lgcc -lc -lgcc
/usr/lib/crtend.o /usr/lib/crtn.o
GNU ld version 2.15 [DragonFly] 2004-05-17
  Supported emulations:
   elf_i386

-- 
           Summary: GCC generates non-compliant warnings for qualifier
                    promotion
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kmk at ssl dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug debug/20230] GCC generates non-compliant warnings for qualifier promotion

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-27 05:30 -------
Note the following warning basically says this is invalid C:
bug2.c:9: warning: passing arg 1 of `safe_function' from incompatible pointer type

use -pedantic-errors and you will see that it is converted to an error.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|debug                       |c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-27 05:32 -------
Quals can only be promoted once.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[kmk at ssl dot org]

------- Additional Comments From kmk at ssl dot org  2005-02-27 06:03 -------
Exactly where does it state that you can only promote one _level_ of qualifier,
as opposed to promoting a single qualifier scope more than once?

Not only that, but even if you declare the string array this way,

char a[8], b[8];
char *const mystrings[2] = { a, b };

it _still_ fails. There is only one level of promotion left here, no matter how
you look at it.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-02-27 11:16 -------
The C standard does in fact not allow this conversion. However,
I agree that it might be nice to have an option for semantics as in the
C++ standard (4.4). They allow this, and it is safe.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[kmk at ssl dot org]

------- Additional Comments From kmk at ssl dot org  2005-02-27 12:48 -------
I'm not sure I understand why it is thought that the C standard forbids the
conversion I'm talking about here. In fact, the final committee draft of the ISO
C standard that I have appears to be silent about the issue of multi-level
pointer conversions entirely. As noted by F. Hueffner, conversion rules are made
quite explicit in the C++ standard:

In ISO/IEC 14882 4.4.4, multi-level pointer conversions are explicitly
constrained by restricting automatic qualifier promotion to only those levels
for which _all_ preceding levels are const. The example that follows the
paragraph furthers the point by noting: "if a program could assign a pointer of
type T** to a pointer of type const T**...a program could inadvertently modify a
const object."

Absolutely. But that's not what I'm talking about. GCC issues an unsuppressible
warning when a conversion is made between:

char *const *object  -->  const char *const *object

or the equivalently innocuous

char **object --> const char *const *object

Nothing I can find in the FCD of the C standard forbids _any_ multi-level
conversion---safe or unsafe. GCC, however, warns about every such conversion
(even though it actually performs them). If it's going to complain, it really
should only complain about unsafe conversions as per the C++ standard---despite
the fact that all conversions appear to be legal in C.

Am I wrong? Where does it state in the C standard that you cannot perform a
multi-level qualifier promotion?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-02-27 13:05 -------
Subject: Re:  New: GCC generates non-compliant warnings for
 qualifier promotion

On Sun, 27 Feb 2005, kmk at ssl dot org wrote:

> "For any qualifier q, a pointer to a non-q-qualified type may be converted to a
> pointer to the q-qualified version of the type; the values stored in the
> original and converted pointers shall compare equal." [section 6.3.2.3, paragraph 2]

All my references in what follows are to the standard itself, C99 as 
amended by TC1 and TC2.  Using drafts is a false economy.

> void safe_function(const char *const *s) { }
> 
> int main(void) {
> 
>   char *mystrings[2] = { "First string", "Second string" };
> 
> // This call warns, but should not:
>   safe_function(mystrings);

The constraints for function calls are not in 6.3.2.3, they are in 
6.5.2.2#2, which references the constraints for assignment in 6.5.16.1#1.

       6.5.16.1  Simple assignment

       Constraints

       [#1] One of the following shall hold:93)

         -- the  left  operand   has   qualified   or   unqualified
            arithmetic type and the right has arithmetic type;

Not applicable.

         -- the left operand has a qualified or unqualified version
            of a structure or union type compatible with  the  type
            of the right;

Not applicable.

         -- both  operands are pointers to qualified or unqualified
            versions of compatible types, and the type  pointed  to
            by  the left has all the qualifiers of the type pointed
            to by the right;

The type on the left is "const char *const *".  That on the right is "char 
**".  These are pointers to "const char * const" and "char *".  These 
types are qualified or unqualified versions of "const char *" and "char 
*".  (Qualification is defined in 6.2.5#25: each of "char *" and "const 
char *" has seven qualified versions, while plain "char *" and "const char 
*" are both unqualified types; note the last sentence of that paragraph, 
"A derived type is not qualified by the qualifiers (if any) of the type 
from which is is derived.", and the definition of pointer types as derived 
types in paragraph 20.)  "const char *" and "char *" are unqualified 
types which are not compatible: compatibility is defined in 6.2.7#1 and 
6.7.3#9 says when qualified types are compatible.  Note that "char" and 
"const char" are not compatible, because they don't have the same 
qualifiers, so "char *" and "const char *" are not compatible, and the 
unqualified version of "const char *const" is "const char *" not "char *" 
by the definition of qualification.

         -- one operand is a pointer to  an  object  or  incomplete
            type  and  the  other  is  a  pointer to a qualified or
            unqualified version of void, and the type pointed to by
            the  left has all the qualifiers of the type pointed to
            by the right;

Not applicable.

         -- the left operand is a pointer and the right is  a  null
            pointer constant; or

Not applicable.

         -- the  left  operand  has  type  _Bool and the right is a
            pointer.

Not applicable.

None of the above apply, so GCC diagnoses the constraint violation.  If 
you want C++ rules, GCC provides a C++ compiler.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2005-02-27 13:20 -------
(In reply to comment #5)

> Am I wrong? Where does it state in the C standard that you cannot perform a
> multi-level qualifier promotion?

Nowhere. It follows from the fact that it is not allowed explicitly in 
6.5.16.1. The demand is:

  -- both operands are pointers to qualified or unqualified versions
  of compatible types, and the type pointed to by the left has all the
  qualifiers of the type pointed to by the right;

but "pointer to char" is not compatible with "const pointer to const char".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[kmk at ssl dot org]

------- Additional Comments From kmk at ssl dot org  2005-02-27 21:37 -------
1. A pointer is a derived type.

2. A derived type is not qualified by the qualifiers (if any) of the type from
which it is derived.

3. For any qualifier q, a POINTER to a non-q-qualified type may be converted to
a pointer to the q-qualified version of the type. [emphasis mine; note that a
pointer is, by itself, a derived type which does not inherit any qualifiers---so
what]

4. A pointer to a pointer is itself a pointer.

5. The C standard, unlike C++, does not further restrict qualifier promotion of
multi-level pointers---in fact, it is completely silent on the issue.

6. By (3), above, the left-hand side of a pointer assignment can be converted so
that all qualifiers match.

I ask again: where is the problem?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[kmk at ssl dot org]

------- Additional Comments From kmk at ssl dot org  2005-02-27 21:43 -------
6. I meant "right-hand side" not "left-hand side".

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-02-27 22:30 -------
Subject: Re:  GCC generates non-compliant warnings for qualifier
 promotion

On Sun, 27 Feb 2005, kmk at ssl dot org wrote:

> 1. A pointer is a derived type.
> 
> 2. A derived type is not qualified by the qualifiers (if any) of the type from
> which it is derived.
> 
> 3. For any qualifier q, a POINTER to a non-q-qualified type may be converted to
> a pointer to the q-qualified version of the type. [emphasis mine; note that a
> pointer is, by itself, a derived type which does not inherit any qualifiers---so
> what]

Indeed, a pointer to non-qualified "char *" may be converted to a pointer 
to qualified "char *".  For example, "char **" or "char **const" may be 
converted to "char *const *" or "char *volatile *const restrict".  But 
"const char *" isn't a qualified version of "char *"; "char *" and "const 
char *" are entirely distinct unqualified types.  So "char **" may not be 
converted to "const char *const *", because they are pointers to distinct 
unqualified types, not pointers to qualified and unqualified versions of 
the same type.

Your misconception appears to be that "const char *" is a qualified 
version of "char *".  It isn't.  They are incompatible unqualified types.  
Similarly, "const char *const *" is not a qualified version of "char **".

> 4. A pointer to a pointer is itself a pointer.
> 
> 5. The C standard, unlike C++, does not further restrict qualifier promotion of
> multi-level pointers---in fact, it is completely silent on the issue.

It doesn't need to discuss the issue, as it follows from the definitions 
in the standard.  There is *no* concept of multi-level pointers in the 
standard; just that of pointers, derived from a type which may or may not 
be a pointer.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230

[Bug c/20230] GCC generates non-compliant warnings for qualifier promotion

[kmk at ssl dot org]

------- Additional Comments From kmk at ssl dot org  2005-02-27 23:12 -------
> But "const char *" isn't a qualified version of "char *"

Ahhh. Now I see your point. Amazingly enough, the C standard does not, under any
circumstances, permit objects (including the targets of pointers) to be
qualifier promoted---only pointers themselves are so provided for.

While that may be _phenomenally_ stupid, I acknoledge that it is, in fact, a
direct interpretation of the standard. Accordingly, I withdraw my objection.
Since the behavior is literally non-compliant with the standard, it is perfectly
reasonable for the compiler to warn about it.

Thank you for the enlightenment.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20230