7

Estoy usando Wind River Compiler 4 (gcc (C) yg ++ (C++)) y compila todos mis proyectos sin ningún problema. Ahora tengo que usar Coverity Static Analysis para verificar mi código. He configurado los compiladores específicos. Para el código C (gcc) no hay problemas y puedo ejecutar el análisis, pero para el C++ - Código (g ++) Tengo un montón de errores:¿Cómo obtener el análisis estático de Coverity compatible con el estándar C++ 0x?

.../c++config.h", line 214: error #40: 
    expected an identifier 
inline namespace __gnu_cxx_ldbl128 { } 
    ^

.../c++config.h", line 214: error #326: 
    inline specifier allowed on function declarations only 
inline namespace __gnu_cxx_ldbl128 { } 
^ 

.../c++config.h", line 214: error #65: 
    expected a ";" 
inline namespace __gnu_cxx_ldbl128 { } 
           ^
.../include/string.h", line 76: error #312: 
    cannot overload functions distinguished by return type alone 
extern __const void *memchr (__const void *__s, int __c, size_t __n) 
        ^

.../include/string.h", line 116: error #312: 
    cannot overload functions distinguished by return type alone 
extern "C++" __const void *memchr (__const void *__s, int __c, size_t __n) 
        ^

Se parece haber cierta C++ 11 características específicas como el espacio de nombres en línea, pero el código no utiliza estas características. Los errores anteriores se producen con una HelloWorld-Code:

#include "stdio.h" 
#include "util.h" 
#include <string> 
#include "string.h" 

using namespace std; 

int main() 
{ 
    printf("Hello World, C++ version: %d.%d.%d\r\n",__GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__); 

    return 0; 
} 

me han tratado de establecer el estándar de C++ con la opción g ++

-std=c++98 

pero el resultado no cambió.

La prueba de código se encuentra en una jerarquía grande de construcción, pero los pasos para Coverity son así:

  1. objetivo y env conjunto (Wind River 4 Linux)
  2. que la limpieza sea
  3. cov-configure dir con el compilador y el tipo
  4. COV-construir con el correcto "hacer toda" comando que trabaja solo
  5. COV-analizar
  6. si (NO_ERROR) COV-comm it-defectos

También he configurado Coverity para reemplazar todo "espacio de nombres en línea" con "espacio de nombres" durante el COV-build (--ppp-translator replace/inline namespace/namespace). Los errores en línea desaparecieron pero produce más de estos errores de sobrecarga y no se genera con éxito. También traté de eliminar el "C++" de la misma manera, pero no funcionó, siempre hay más errores.

¿Alguien tiene una idea de cuál es el problema aquí? ¿Y cómo puedo obtener la compilación de Coverity sin errores? Tal vez puedo configurar Coverity para ignorar los encabezados estándar de C++, pero ahora no sé cómo hacerlo.

+0

¿Qué versión de gcc estás usando? 4 no es lo suficientemente específico. De todos modos, debe abrir un caso con [email protected]; envíeles su registro de compilación y su fuente preprocesada, y ellos podrán decirle lo que necesita agregar a su configuración para permitir que cov-emye procese satisfactoriamente. –

+0

The WindRiver Env. es WR-Linux-4.0/Toolchain-4.4-291 y el gcc que se utiliza parece ser la versión 4.4.1. Esa es la versión del directorio de inclusión de gcc durante el script de compilación. Ahora también estoy en contacto con el soporte: el problema es que especialmente WindRiver Compiler no es compatible con Linux, pero casi * cualquier * compilador gcc. Ahora tienen la fuente preprocesada y la examinan. También el soporte WindRiver ahora está involucrado. – Indimental

+0

Recibimos respuesta del servicio de asistencia de Coverity y ahora estamos tratando de hacer una solución. – Indimental

Respuesta

4

Solución de Soporte Coverity:

El espacio de nombres en línea es un error conocido de Coverity. Para pasar por alto que, configurar Coverity con las siguientes opciones adicionales (en el archivo de configuración):

<begin_command_line_config></begin_command_line_config> 
    <add-arg>--ppp_translator</add_arg> 
    <add_arg>replace/inline namespace ([_a-zA-Z0-9]*)\s+\{\s*\}/namespace $1 { } using namespace $1;</add_arg> 
</options> 

Después de que nos dieron algunos otros errores pero parecen pertenecer a toda la cadena de caracteres. Ahora añadir un Coverity definir al principio de Coverity-compilador compat.h (también en el directorio config):

#define __COVERITY_NO_STRING_NODEFS__ 

Después de estos cambios, el COV-build se ejecuta sin errores y el análisis se puede iniciar.

0

Este error lo dice con toda claridad:

línea especificador permitidos en las declaraciones de función única

¿Hay alguna razón el espacio de nombres es inline? Si bien no tengo la especificación disponible, entonces no puedo decirte si está permitida o no. (Que el compilador lo permita puede ser un error en GCC.)

Trate de eliminar ese inline y Coverity con suerte se alegrará.

Parece que Coverity no se ha actualizado con algunas funciones de C++ 11, como espacios de nombres en línea.

+0

Ese es el problema. Nunca he usado esto "en línea" y no sé por qué está ahí. Me olvidé de escribir que también he configurado Coverity para reemplazar todo "espacio de nombres en línea" con "espacio de nombres", pero luego aparecen más problemas como los dos últimos. – Indimental

+0

espacios de nombres en línea son una característica de C++ 11. Principalmente para versionar una implementación de biblioteca. – bames53

+0

@Indimental no se puede simplemente reemplazar espacios de nombres en línea con espacios de nombres, no hacen lo mismo, por lo que la implementación de la biblioteca simplemente no funcionará y Coverity no tendrá ninguna esperanza de analizarla correctamente. – bames53

5

La implementación de su biblioteca utiliza C++ 11. Presumiblemente hay #ifdefs que eliminan todas las cosas de C++ 11 cuando llamas a g ++ con -std=c++98 pero parece que, sin embargo, Coverity está integrado con g ++, no define las mismas cosas que son necesarias para evitar las características de C++ 11.

Debe averiguar cuáles son las macros que utiliza gcc en torno a ese código C++ 11 y luego asegúrese de que Coverity también las defina adecuadamente cuando analice su proyecto.

+0

Parece que hay algunas definiciones aquí descritas: http://stackoverflow.com/questions/2958398/gnu-c-how-to-check-when-std-c0x-is-in-effect pero no puedo encuentra cualquier conexión a las líneas de error. Las líneas de error tienen que ver con el modelo largo de doble 128 bits y no dependen de una de las definiciones de C++ 0x. También debo decir que soy totalmente nuevo en esas cosas de compilador de profundidad. – Indimental

+0

¿Han cambiado los mensajes de error de Coverity al hacer que Coverity use los que define C++ 0x? Puede haber otras definiciones que necesita. Puede hacer que gcc liste todo lo que define y luego usar eso como una base para lo que necesita definir para Coverity, o simplemente puede examinar los archivos de encabezado para ver lo que verifican. – bames53

+0

Cuando uso el estándar C++ 0x, los primeros 3 errores son los mismos. Los dos últimos se reemplazan por errores en "stringfwd.h": el identificador "char32_t" no está definido: template <> struct char_traits ; lo mismo para el identificador "char16_t". ¿Puede ser que la compilación de Coverity incluya algunos encabezados predeterminados y que sean incompatibles con las inclusiones nativas? Entonces, hay algo sobreescrito y bloquea la configuración del encabezado. – Indimental

Cuestiones relacionadas