• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 6200 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: Error " a const_cast can only adjust type qualifiers; it cannot change the underlying type" although underlying type not changed

Dan Cermak
Intellectual 690 points

Tool/software: TI C/C++ Compiler

I have found a little oddity with TI's armcl compiler, it reports the error "a const_cast can only adjust type qualifiers; it cannot change the underlying type" when a variable is cast to a typedef via const_cast that does not involve a conversion. It can be reproduced with the following example:

extern "C" void (*const interruptVectors[])();

typedef void (*ISR_t)(void);

static ISR_t* source_vector_table = const_cast<ISR_t*>(interruptVectors);

armcl does not compile this, although I think there is no error as interruptVector is of type const ISR_t*. gcc and clang both compile the snippet with -Wall -Wextra -Wpedantic and only report the unused variable source_vector_table.

  • 0
    TI__Prodigy 625 points

    It is true that const_cast exists solely to convert a cv-qualified type T to a different cv qualified type T. However, according to the standard, the type of the symbol interruptVectors[] and the type of the typedef ISR_t represent different types, thus making any const_cast from one to the other illegal.

    According to 7.5.1 of the C++03 standard, two names with different 'language linkage' are distinct types, even if they are otherwise identical.

    Our compiler enforces this requirement, while both gcc and clang do not. The following code works as desired:

    extern "C" void (*const interruptVectors[])();

extern "C" {
  typedef void (*ISR_t)(void);
}

static ISR_t* source_vector_table = const_cast<ISR_t*>(interruptVectors);

  • 0 in reply to James Nagurne
    Intellectual 690 points
    Ah, I see. Did not know that, thanks for clarifying that!