|Lo que no hay que hacer en C/C++. Nivel basico|

[Littlehorse]

Este articulo también se encuentra en wiki.elhacker.net,

Código [Seleccionar] Expandir

http://wiki.elhacker.net/programacion/cc/articulos/lo-que-no-hay-que-hacer-en-c-c

La mayoría que recién esta empezando con C/C++ y viene al foro a sacarse dudas, cometen errores similares. Incluso muchos tienen conceptos erroneos sobre la utilidad o eficiencia de ciertas funciones, probablemente debido a el estudio de textos incorrectos o de libros anticuados.

Pero incluso a veces uno no puede escapar de ciertas cosas. Imaginen a alguien que recién entra en la universidad y el profesor le hace incluir conio para utilizar getch. Seguramente el alumno de por sentado que hacer eso esta perfecto, e incluso el profesor recompense con notas altas a los que programan tal cual se ha enseñado.
Por lo tanto, ciertas cosas son comprensibles y el único consejo que se puede dar es que nunca den por sentado algo, es recomendable informarse antes para ver que es lo que se esta realizando, sobre todo en programación.

Para los que quieran revisar un poco explicaciones mas detalladas del "por que" de ciertas reglas, puede revisar este draft, que aunque puede tornarse bastante técnico para alguien que recién comienza, puede servir bastante:

WG14/N1256 Committee Draft — Septermber 7, 2007 ISO/IEC 9899:TC3 (Gracias Queta)


1) gets();

La falta de control en un programa es un factor bastante negativo, y también peligroso en caso de programas comerciales o masivos. Ese es el principal problema de gets, no tiene control interno.

¿Que signifca no tener control interno?

Significa que la funcion acarrea como consecuencia el mal comportamiento del programa, resultados inesperados y erroneos, vulnerabilidades entre otras tantas cosas.
Define una cadena de 10 caracteres, y gets va a aceptarte eso y muchisimo mas como entrada.

Veamos este codigo:

Código (c) [Seleccionar] Expandir

#include<stdio.h>

int main()
{

char letra1[]="AAAAA";
char letra2[]="BBBBB";
char letra3[]="CCCCC";

printf("A: %s\nB: %s\nC: %s\n\n",letra1,letra2,letra3);

printf("Ingrese la letra D, 5 veces: ");
gets(letra2);

printf("\nA: %s\nB: %s\nC: %s\n\n",letra1,letra2,letra3);

getchar();
}

Código [Seleccionar] Expandir

A: AAAAA
B: BBBBB
C: CCCCC

Ingrese la letra D, 5 veces: DDDDD

A: AAAAA
B: DDDDD
C: CCCCC

Como vemos nada paso, y los elementos de letra2 se reemplazaron por el input ingresado como debería ser . Ahora en vez de 5 veces, ingresemos la letra 'D' mas veces de lo que el programa nos indica:

Código [Seleccionar] Expandir


A: AAAAA
B: BBBBB
C: CCCCC

Ingrese la letra D, 5 veces: DDDDDDDDDDDDDDDDDDD

A: DDD
B: DDDDD
C: CCCCC

Que paso con letra1? precisamente lo que no queremos que pase en nuestro programa. gets sobreescribio una zona de memoria que no debia sobreescribir, ya que el input debia ser ingresado en letra2, pero simplemente no le importo que el input sea muchisimo mas grande que el tamaño de la cadena. Razon mas que suficiente para no utilizarla.

Por lo tanto es recomendable utilizar fgets();

Código (c) [Seleccionar] Expandir

fgets(char *string, int length, FILE * stream)

Es decir:

Código (c) [Seleccionar] Expandir

fgets(letra2, 5, stdin);

Con fgets permites que sean ingresados lenght-1 caracteres.
Aunque no todo es color de rosas, y en caso de que se ingresen menos caracteres de los que has definido como tamaño, tendras que lidiar con un salto de linea '\n'. Obviamente es una nimiedad que puedes arreglarla de esta forma:

Código (c) [Seleccionar] Expandir

if (letra2[strlen(letra2)-1] == '\n')//string.h para strlen();
letra2[strlen(letra2)-1] = '\0';

Supongo que con esto queda claro que no tiene sentido utilizar gets();.

Links:
http://en.wikipedia.org/wiki/Fgets
http://www.gidnetwork.com/b-56.html


2) fflush(stdin);

fflush(stdin) es un invitado casi diario. Pocas veces pasa un dia sin que alguien lo recomiende o lo mencione como la solucion! a los malos comportamientos de las pausas en los programas.

STDIN, como su nombre lo indica, significa 'Standard input'. Es decir, el ingreso por teclado.

Acorde al Standard, fflush espera solamente un stream de salida (STDOUT: 'Standard Output) por lo que el comportamiento con streams de entrada como STDIN es indefinido. Por mas que en algunas plataformas funcione, o que en algunos compiladores funcione, no deberia ser utilizado.

Por el otro lado, para evitar esas pausas fastidiosas es necesario evitar las funciones que dejan basura por doquier (como scanf();) y utilizar funciones como la ya mencionada fgets();


http://foro.elhacker.net/programacion_cc/fflushstdin-t91101.0.html
http://foro.elhacker.net/programacion_cc/zanjar_de_una_vez_fflushstdin-t265125.0.html;msg1294511
http://foro.elhacker.net/programacion_cc/error_super_basico_en_c_quien_me_ayuda_soy_nuevo-t262118.0.html;msg1275898
http://foro.elhacker.net/programacion_cc/problema_con_el_compilador_gcc_de_ubuntu-t248582.0.html




3) system("PAUSE");

Otro invitado diario es la pausa utilizando system. Esto incluso me ha tocado en mi universidad. Que el profesor me haga realizar ejercicios exclusivamente utilizando system y la pausa tambien habia que realizarla exclusivamente utilizando system. En fin, seguramente muchos consideren que realizar esto no es un gran problema, y probablemente tengan razon en los codigos que uno realiza como tarea estudiantil. Pero es un habito malo, y como todo, hay que dejarlo algun dia. Claramente no puedes pasarte toda la vida llamando al sistema para hacer una pausa.

*No es portable, solo va a funcionar en sistemas que tengan el comando PAUSE.

*Es una funcion pesada. Llamar al sistema, suspender tu programa, buscar el comando PAUSE, etc etc etc etc.

Por el otro lado si se siguio la norma de no dejar basura en el buffer de entrada, se puede utilizar soluciones mas sencillas como getchar(); (o cin.get(); en C++).


4) conio.h

Librerias inutiles si las hay, pero por sobre todas las cosas NO standard. No existe problema para el cual sea exclusivamente necesario utilizar conio.h. Y visto que aca la mayoria de los que la incluyen lo hacen para utilizar getch(); supongo que con todo el parrafo anterior habran quedado claras las alternativas.

http://en.wikipedia.org/wiki/Conio.h
http://www.gidforums.com/t-7379.html


5) void main();

Seguramente para justificar esto habría que decir que el estándar dice que void no puede ser el valor de retorno del main, lo cual es verdad, pero no siempre es suficiente. Sobretodo considerando que muchas veces en los libros el void main dice presente.

No voy a extenderme mucho con esto ya que voy a dejar los links necesarios para el que quiera entender porque sucede, pero como base comprendamos esto:

-Devolver un valor void es perder la garantia que un valor de retorno distinto de 0 implica un error, lo cual es malo tanto para el SO como para el determinado programa que pueda estar llamando a tu código.

-Esta mal acorde al estándar.

-Puede que tu programa no funcione correctamente.

Los errores pueden depender de los mecanismos de retorno o la arquitectura especifica en la cual estemos. Pero por supuesto, si elegimos un lenguaje de alto nivel como lo es C o C++, es para no tener que preocuparnos por esos asuntos.

En conclusión, el que quiera entender el " por que", leer los siguientes links.

Links:

http://www.eskimo.com/~scs/readings/voidmain.960823.html
http://home.att.net/~jackklein/ctips01.html#int_main
http://users.aber.ac.uk/auj/voidmain.shtml


6) Procesamiento de cadenas: string.h

La mayoría de las funciones que no tienen la posibilidad de pasar como argumento el tamaño del buffer que debe procesarse, estan completamente expuestas al desbordamiento de buffer. Sobre todo si el contenido del buffer origen es ingresado por el usuario, y por sobre todas las cosas, si no se hicieron las validaciones correspondientes. (Por ejemplo, haber utilizado gets o no haber chequeado el tamaño de la cadena antes de copiar/concatenar o cualquier otra forma de procesar una cadena).
Obviamente no voy a hablar sobre todas las funciones, pero si sobre dos ejemplos que dan la pauta de lo que sucede y de lo que debería hacerse: strcpy y strcat.

a) strcpy ( char * destination, const char * source );

Veamos un ejemplo de un codigo incorrecto:

Código (c) [Seleccionar] Expandir

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

int main()
{
char cadena1[]={"aaaa"};
char cadena2[100];
char cadena3[]={"0123"};

printf("Ingrese cadena: ");
fgets(cadena2,100,stdin);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s\n\n",cadena1,cadena2,cadena3);
strcpy(cadena1,cadena2);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s",cadena1,cadena2,cadena3);
getchar();
return 0;
}

Código [Seleccionar] Expandir

Ingrese cadena: 1111111111111111111111111111111111111111111111111111

//Antes de strcpy
cadena1: aaaa
cadena2: 111111111111111111111111111111111111
cadena3: 0123

//Despues de strcpy
cadena1: 111111111111111111111111111111111111
cadena2: 111111111111111111111111111111111111
cadena3: 1111111111111111111111111111111111111111111111111111


Como se ve claramente, el problema esta vez no estuvo en la recepción de los datos (en el sentido técnico), si no en el copiado. Ya que strcpy no verifica si el buffer destino es efectivamente capaz de contener los datos del buffer origen, lo cual por supuesto ocasiona perdida de datos y buffers overflows.
Obviamente si el fgets se hubiese utilizado correctamente, esto no hubiese sucedido.

b) strcat ( char * destination, const char * source );

La misma historia sucede aqui. Al no poder especificar el tamaño del buffer destino la funcion es insegura. Veamos un ejemplo incorrecto:

Código (c) [Seleccionar] Expandir

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

int main()
{
char cadena1[]={"aaaa"};
char cadena2[100];
char cadena3[]={"0123"};

printf("Ingrese cadena: ");
fgets(cadena2,100,stdin);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s\n\n",cadena1,cadena2,cadena3);
strcat(cadena1,cadena2);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s",cadena1,cadena2,cadena3);
getchar();
return 0;
}

Código [Seleccionar] Expandir

Ingrese cadena: 11111111111111111111111111111111111111111111

//Antes de strcat
cadena1: aaaa
cadena2: 1111111111111111111111111111
cadena3: 0123


//Despues de strcat
cadena1: aaaa1111111111111111111111111111
cadena2: 1111111111111111111111111111
cadena3: 11111111111111111111111111111111111111111111

Como pueden ver suceden errores muy similares. Obviamente es un error tonto de programación en el cual el desarrollador pasa un mal argumento a fgets, ya que de haberlo hecho bien el error no sucederia. Pero ese no es el asunto, lo importante es que tanto strcpy o strcat (y toda la familia de funciones) no realizan (o permiten realizar) la validación extra necesaria. Imaginen que creas una cadena para tomar una ruta del sistema operativo para luego concatenar, ¿Y si el atacante se da cuenta de eso y decide explotar el overflow por ese lado? mil variantes pueden existir y probablemente no siempre uno cubra todas ellas.

c) Entonces que se puede utilizar?

strncpy y strncat cumplen su función perfectamente si se utilizan en forma correcta.

c1) strncpy ( char * destination, const char * source, size_t num );

Código (c) [Seleccionar] Expandir

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

int main()
{
char cadena1[]={"aaaa"};
char cadena2[100];
char cadena3[]={"0123"};

printf("Ingrese cadena: ");
fgets(cadena2,100,stdin);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s\n\n",cadena1,cadena2,cadena3);
strncpy(cadena1,cadena2,1);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s",cadena1,cadena2,cadena3);
getchar();
return 0;
}

Código [Seleccionar] Expandir

Ingrese cadena: 1111111111111111111

//Antes de strncpy
cadena1: aaaa
cadena2: 1111111111111111111
cadena3: 0123

//Despues de strncpy
cadena1: 1aaa
cadena2: 1111111111111111111
cadena3: 0123

c2) strncat ( char * destination, const char * source, size_t num );

Código (c) [Seleccionar] Expandir

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

int main()
{
char cadena1[]={"aaaa"};
char cadena2[100];
char cadena3[]={"0123"};

printf("Ingrese cadena: ");
fgets(cadena2,100,stdin);
printf("cadena1: %s\ncadena2: %s\ncadena3: %s\n\n",cadena1,cadena2,cadena3);
strncat(cadena1,cadena2,0);//Obviamente esta linea es un absurdo
//Pero queda claro el control que la funcion mantiene
printf("cadena1: %s\ncadena2: %s\ncadena3: %s",cadena1,cadena2,cadena3);
getchar();
return 0;
}

Código [Seleccionar] Expandir

Ingrese cadena: 123123

//Antes de strncat
cadena1: aaaa
cadena2: 123123
cadena3: 0123

//Despues de strncat
cadena1: aaaa
cadena2: 123123
cadena3: 0123

Estas ultimas funciones a pesar de poder utilizarse perfectamente como solucion a lo anterior expuesto, tambien tienen sus contras:

-Tanto strncpy o strncat no proveen un valor de retorno que pueda implicar un error o el exito de la cadena resultante, si no que devuelven un puntero al buffer destino. Por lo tanto requiere un esfuerzo extra por parte del programador.

- strncpy no finaliza la cadena resultante con null si el destino es al menos igual en tamaño que el origen, por lo tanto siempre debe finalizarse la cadena con null después de la llamada a strncpy.

- strncpy tambien tiene un comportamiento que puede afectar el rendimiento del programa en caso que el buffer destino sea considerablemente mas grande que el buffer origen, ya que en este caso se realiza el zero-padding, es decir, llena el resto de la cadena con nulls.

Microsoft tiene una lista de funciones baneadas (lo que en Visual Studio se conoce como deprecated) y obviamente tiene el reemplazo de estas llamandolas funcion_s. Ejemplo: strcpy_s, strcat_s, gets_s y etc.
Pueden ver las funciones catalogadas como inseguras en este header, y su reemplazo en esta lista. (Gracias Vertex por los links)

Tambien existen opciones como strlcpy y strlcat, las cuales pueden ver a fondo en este link.


------------------------------------------------------------------------------------------

Continua

[invisible_hack]

Buen post, por lo menos a mi me será útil jeje

Y pues sí, yo también pienso que hay que evitar usar system ya que es como usar comandos de Ms-Dos en C/C++ y pues si estamos con C, programamos en C, y si estamos con Batch, usamos comandos del cmd, en ese caso sí...

Edito: acabo de ver que le han puesto chincheta, se la merece si señor jeje 

Saludos.

[isseu]

muy util, muchas gracias

[xtermsh]

Muy bueno littlehorse, por fin un aporte que sirve, quizas con el tiempo lo puedas ampliar, sería genial.

[WaRc3L]

Genial Idea Littlehorse ! 

Espero que se vaya ampliando... 

Saludos!

WaRc3L

[Jaixon Jax]

 

 Buena explicacion yo agregaria las funciones de manejo de cadenas que tienen vulnerabilidades graves espero la proxima entrega  

 Saludos ....

[Foxy Rider]

hay mucho que se le podría agregar, pero, es tarde, tengo sueño y no se me ocurre que ahora 

lo que me llega a la mente por lo que mencionó jaixxon es de  agregar las funciones "baneadas" por microsoft --> http://msdn.microsoft.com/en-us/library/bb288454.aspx (banned.h ->  http://download.microsoft.com/download/2/e/b/2ebac853-63b7-49b4-b66f-9fd85f37c0f5/banned.h )



Saludos ~

[O-LLOS-O]

Esta muy bien gracias!!!

hay mucho que se le podría agregar, pero, es tarde, tengo sueño y no se me ocurre que ahora 

lo que me llega a la mente por lo que mencionó jaixxon es de  agregar las funciones "baneadas" por microsoft --> http://msdn.microsoft.com/en-us/library/bb288454.aspx (banned.h ->  http://download.microsoft.com/download/2/e/b/2ebac853-63b7-49b4-b66f-9fd85f37c0f5/banned.h )



Saludos ~

microsoft ha baneado funciones?xdxdxdxdxd

[.;.]

Bien, bien


Buen post, al fin alguien que se dispone a hacer algo para el movimiento anti-conio

Y demás "fallos" típicos.

Gracias littlehorse

[goditozor]

Hola littlehorse excelente post, disculpa mi ignorancia tengo una preguntita que esto de los flujos.

cito

"fgets(char *string, int length, FILE * stream)"

cuando se usa stdin o algun otro no me ha quedado claro ese parametro..?