[LLVMbugs] [Bug 24022] New: const with type safety checking [-Wtype-safety]

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Thu Jul 2 13:58:00 PDT 2015


https://llvm.org/bugs/show_bug.cgi?id=24022

            Bug ID: 24022
           Summary: const with type safety checking [-Wtype-safety]
           Product: clang
           Version: 3.6
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jed at 59a2.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

MPI-3 changed read-only buffer arguments to use const.  Clang's type tag system
is sensitive to const, meaning that a tag created for non-const cannot be used
for const without triggering a warning.  For example, the following triggers a
warning:

$ cat warning.c
#define DATATYPE_INT 1
typedef int Datatype;
void f(const void *buf, Datatype tag)
__attribute__((pointer_with_type_tag(X,1,2)));
static const Datatype X_datatype_int
__attribute__((type_tag_for_datatype(X,int))) = DATATYPE_INT;

void foo(const int *data) {
  f(data,DATATYPE_INT);
}
$ clang -c -Wtype-safety warning.c 
warning.c:7:5: warning: argument type 'const int *' doesn't match specified 'X'
type tag that requires 'int *' [-Wtype-safety]
  f(data,DATATYPE_INT);
    ^~~~ ~~~~~~~~~~~~
1 warning generated.

This causes superfluous warnings in idiomatic user code and has forced MPICH to
disable type tag checking with current Clang.

http://trac.mpich.org/projects/mpich/ticket/2223

It would be much more useful behavior to let the normal C type system handle
const versus non-const arguments/conversions and have the tag system be
agnostic.  Alternatively, make it possible to declare tags that are agnostic.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150702/e46fc852/attachment.html>


More information about the llvm-bugs mailing list