instalar - MinGW no produce advertencias
mingw windows 10 (1)
He instalado con éxito MinGW en una máquina con Windows 7 de 32 bits, y he intentado compilar un programa simple usando la línea de comandos o la consola MinGW.
El código tiene un error intencional en una declaración printf:
#include <stdio.h>
#include <stdlib.h>
int main( void )
{
printf("%d/n" , 3.14 ) ;
return 0 ;
}
El comando gcc -Wall hello.c muestra una advertencia correcta: hello.c: 7: 2: advertencia: el formato ''% d'' espera un argumento de tipo ''int'' ...
Pero el comando gcc -std=c99 -Wall hello.c no da ninguna advertencia.
Ambos crean un ejecutable a.exe (que se ejecuta y da el mismo resultado).
(Curiosamente, un comando gcc -std=gnu99 -Wall hello.c muestra la advertencia).
No sé si esto es un error, o la instalación salió mal de alguna manera, pero ambas parecen poco probables ya que el compilador funciona y compiló exitosamente un proyecto más grande (pero la misma advertencia, por supuesto, se omite al usar -std = c99).
Debo faltar alguna información.
(ps: si alguien tiene una nueva instalación de MinGW, prueba esto).
gcc versión 4.8.1 (GCC)
Actualización 1:
Definir _GNU_SOURCE antes de incluir stdio.h elimina la advertencia incluso con gcc -Wall hello.c .
Actualización 2 (podría ser menos relevante):
Compilando
printf("%lf/n" , 3.14 ) ;
-std=c99 salidas de bandera -std=c99 : 0.000000
-std=gnu99 salidas gnu99: 3.140000
Y compilando:
printf("%f/n" , 3.14 ) ;
-std=gnu99 y -std=c99 salida: 3.140000
Actualización 3:
Las funciones que parecen estar afectadas son: printf, fprintf, snprintf, sprintf.
El problema con la falta de advertencia al usar la opción std=c99 parece que se debe a que MinGW 4.8.1 preprocesa stdio.h un poco diferente para la familia de funciones printf() cuando se -std=c99 comparación con cuando -std=gnu99 Se utiliza -std=gnu99 .
Nota: estoy viendo MinGW 4.8.1 de TDM. Creo que otras distribuciones pueden diferir en estos detalles.
MinGW ha tenido algunos problemas de compatibilidad con el formato de valores de punto flotante debido a su dependencia histórica de msvcrt.dll para el tiempo de ejecución de C y al hecho de que MSVC usa una representación de 64 bits por long double mientras que gcc usa una de 96 bits (o de 128 bits). en x64) representación. Ver gcc: printf y largos conductores dobles a salida incorrecta. [C - La conversión de tipos se desordena] para algunos detalles. Las versiones más recientes de MinGW han proporcionado su propia implementación de la familia de funciones printf() (con el prefijo __mingw_ en el nombre) en libmingwex.a para resolver esos problemas.
Los archivos de encabezado _mingw.h y stdio.h configuran si se libmingwex.a o no las implementaciones libmingwex.a o las implementaciones msvcrt.dll .
Parece que si se solicita el cumplimiento con ANSI, MinGW usará las implementaciones libmingwex.a (también hay otras formas de obtener esta configuración; consulte los encabezados para obtener más información). La conexión de una llamada de usuario a printf() a la implementación __mingw_printf() en libmingwex.a se realiza mediante stdio.h definiendo una implementación estática en línea de printf() que es una envoltura delgada alrededor de una llamada a __mingw_vfprintf() . Aparentemente, el -Wformat no se aplica a las versiones de las funciones de la familia printf() que el compilador no cree que -Wformat parte de la biblioteca (una suposición razonable: el compilador realmente no sabe nada acerca de esas funciones). Este problema se puede solucionar aplicando el atributo de función apropiado (por ejemplo: __attribute__ ((format (printf, 1, 2))) ) a las funciones de envoltura en línea estática.
El otro problema que encontraste, donde printf("%lf/n", 3.14) imprime 0.000000 al usar std=c99 , parece ser un error en la implementación __mingw_vfprintf() de __mingw_vfprintf() . Parece que __mingw_vfprintf() interpreta erróneamente que "%lf" significa que el argumento es un long double . No estoy muy sorprendido por eso, siempre tengo que mirar si %lf significa double o long double .