Pero o sea, puedo ir tocar los interruptores de la forma que yo quiera y despues volver a las habitaciones una sola vez? o tengo que ir directo a los interruptores y ya sin volver a las lamparas saber a cual pertenece cada uno?

 , imposible. Se me ocurre como hacerlo si tengo que ir al cuarto donde estan las lamparas despues de haber ido solo una vez al de los interruptores, pero si es al revez sera alguna trampa con electricidad.

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

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:

#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();
}

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:


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();

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

Es decir:

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:

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:

#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;
}

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:

#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;
}

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 );

#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;
}

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

#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;
}

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

Si, asi es correcto. Podes usar un else para luego poner el codigo para MAC.
clear podria funcionar pero de seguro trae problemas por el tema de la consola.

Yo dejaria el codigo asi para mantenerlo limpio. Eso si, las llamadas a system no me gustan para nada, pero si lo queres estandar solo puedes codificar tus propias funciones, y de seguro agregas codigo que tal vez sea innecesario.
Evitar la compilacion condicional de seguro es complicado si queres una funcion estandar para limpiar la pantalla.

Me refiero a algo asi con el tema de la pausa:

#include <stdio.h>
#define PAUSE printf("Presiona una tecla..."); fgetc(stdin);
 
int main()
{
  PAUSE
  return 0;
}  

Esto lo digo como detalle, como ya dije, para tareas como esa llamar a system no es un problema importante.    

Un saludo!

Esta bastante bien el codigo, como consejo te diria que en vez de pensar en sumarle opciones le mejores la portabilidad. No tiene sentido que sea exclusivo de Windows solamente por system y fflush  .

Un saludo!

Tal vez debas preguntar por aquí

Un saludo.

Si pero precisamente en ese caso estas reemplazando data aunque no sea util. Obviamente hay muchas variantes, la esteganografia (que por cierto de hacking barato no tiene nada ) es un mundo inmenso.

Me acuerdo que esa misma respuesta se habia dado aqui pero sinceramente no pense que eso te iba a servir.

Un saludo

Fisicamente el archivo siempre va a ser mas grande. Otro punto seria que el tamaño del contenido en el area no usada del archivo no pueda ser determinado. Pero el archivo fisicamente siempre sera mas grande por mas que el visualizador muestre otro tamaño.
Si te referis a que "virtualmente" el modificado tenga el mismo tamaño que el original, es posible, ahora si quieres que fisicamente lo tengan, me gustaria a mi ver la respuesta  

En cuanto a lo del virus, bueno, lo detectara en ejecucion o por heuristica, dependera del AV  .

Tal vez te sirva esto

http://paper.ijcsns.org/07_book/200907/20090730.pdf

Y este otro que tambien habla de lo que menciono Novlucker

http://www.windowsecurity.com/articles/Alternate_Data_Streams.html

De hacker nada, es un plug-in del AMX.

amx_ejectcd.

Un saludo

Entonces no se. A mi me da error en Ubuntu, en Debian, y en Windows con IE, Chrome y Firefox. Asi que no se me ocurre porque lado viene el error