Si son GPL, entonces sí tienes derecho a distribuirlos y venderlos (y ya que estamos, puedes cobrar básicamente lo que quieras. Hay quien cree que sólo puedes cobrar el costo de la copia o soporte, pero eso es falso). La licencia impone ciertas obligaciones, como sabrás si la has leído, pero no necesitas el permiso de nadie para venderlos. Otra cosa es que Mercado Libre Venezuela pueda tener políticas propias que lo prohíban, y si es así, no hay mucho que puedas hacer, salvo buscar alguna otra plataforma.

No había visto que escribiste algo más.

El problema es que pones el _getch fuera del while. Lo que debes hacer es cambiar esto:

cin >> tecla;

por:
 

tecla = _getch();

No, no es así. La que hace eso es GetKeyboardState. _getch espera hasta que haya algo en su buffer (que es distinto del de stdin), y luego lo lee y devuelve el valor.

Falta información. ¿Eso compila siquiera, o te da algún error? ¿Qué tipo de dato es materias? Preferentemente deberías poner la declaración de toda la estructura Alumno.

Ya de entrada, con ese código no vas a poder modificar ninguna cadena, ya que ese iterador trabaja sobre copias. Necesitarías que fuera una referencia. De cualquier manera, si materias es un vector de cadenas, entonces it[ n ] sólo se refiere al caracter "n" de cada cadena en cuestión, por lo que no es válido asignarle una cadena ni compararlo con una. Pon la información que te digo y ya podríamos ver exactamente cuál es el error.

La forma más sencilla es usar _getch, declarada en conio.h. La aclaración pertinente (porque hay mucha información equivocada u obsoleta al respecto): aunque es sólo para Windows (lo cual claramente no es un problema en tu caso), actualmente es parte oficial de sus APIs, así que debería funcionarte con cualquier compilador para este SO sin necesidad de instalar nada extra.

También podrías implementar esta funcionalidad mediante SetConsoleMode, pero no le veo mucho caso, cuando _getch ya hace todo el trabajo sucio (internamente llama a SetConsoleMode y ReadConsoleInput).

Es cierto que el problema se resuelve limpiando el buffer, pero fflush(stdin) no es lo correcto. Esta función sólo sirve para buffers de salida, no de entrada, como stdin. Usarlo con stdin funciona de casualidad en Windows, siempre que uses MinGW. Si usas, por ejemplo, alguna versión reciente de Visual C++, no funciona, y tampoco sirve en Linux, independientemente del compilador. Como se trata de un ejercicio simple y no estás validando entrada ni verificando errores, puedes limpiar el buffer con esta línea después del scanf:

while (getchar() != '\n');

Creo que conviene aclarar por si acaso. Aunque -Os y -s pueden reducir bastante el tamaño de los binarios, tienen sus desventajas. Compilar optimizando para reducir el tamaño puede reducir también el rendimiento (al menos en comparación con -O2 y -O3, que optimizan para velocidad de ejecución sin importar el tamaño), y en particular -s quita información que puede ser útil (aunque no indispensable en este caso para la ejecución del programa).

Aquí las puse porque podían servir para verificar que era un falso positivo y como un ejemplo de cómo las opciones de compilación influyen en el tamaño del ejecutable, pero en general sólo habría que usar ésas, y en especial -s, cuando hay una necesidad específica para hacerlo y se sabe lo que hace; de lo contrario no es muy recomendable.

Viendo el código, no hace nada raro, así que probablemente, como ya te dijeron, se trate de un falso positivo. La diferencia de tamaños no tiene nada de extraño, y depende del compilador usado, las opciones de compilación, etc. Por ejemplo, tan sólo con los análisis de VirusTotal, se puede ver que tú estás compilando para 64 bits, mientras que el .exe original fue compilado para 32 y con un compilador viejísimo (según el reporte, fue compilado en 2002...) así que no tiene el menor sentido comparar los tamaños.

Dicho lo anterior, si lo compilas, por ejemplo, con las opciones  -Os -s, debería reducir de forma importante el tamaño, y es posible que el falso positivo (si lo fuera) desaparezca.

  Para nada; de hecho es más bien al contrario. No sólo no es necesario usar la notación húngara sino que prácticamente nadie lo hace. Se usaba dentro de Microsoft, y a veces por consistencia al programar con la API de Windows, pero nada más. Su uso jamás estuvo extendido fuera de ese ámbito, y es casi universalmente rechazada, motivo de burlas y abiertamente desaconsejada y criticada en el propio comité de C++ desde hace años. Incluso dentro de Microsoft ha quedado prácticamente en desuso en la actualidad.

Si se trata de optimizaciones del compilador, es difícil saber qué está pasando sin ver el código exacto, porque son muy específicas para cada caso.

En general, optimizaciones así de agresivas sólo son permitidas si: 1) estás haciendo algo indebido o que resulte en UB (por ejemplo, usar punteros no inicializados), ó 2) el compilador determina que el comportamiento "observable" del programa no se ve alterado. Por ejemplo, si llamas a una función y luego no haces nada "útil" con el resultado (como imprimirlo, guardarlo en un archivo, mandarlo por un socket, pasarlo a una función externa, etc.), el compilador es libre de omitir por completo la llamada si determina que la función tampoco hace nada que tenga un efecto observable.

Algo de lo anterior debe ser la causa. De lo contrario, y a menos que esté pasando por alto algo, no hay razón para que GCC te altere el código de esa forma.

¿Qué opciones activas en GCC? Si usas -O, -O2, etc., prueba a quitarla y ve el código generado. Otra cosa a probar, con fines de diagnóstico y para corroborar que GCC no sea el problema, es que la función que hace algo con el puntero esté definida en un archivo fuente (ojo, fuente, no de cabecera, pues la idea es que se compilen por separado) distinto a aquél en el que la invocas y declaras el puntero a pasarle. Sólo asegúrate de que la función use el puntero recibido para algo que tenga un efecto externo (puede ser algo tan simple como retornarlo tal cual). Si aún así hace lo mismo, puede haber algo mal en tu código, por lo que podrías probar a compilar, por ejemplo, con -Wall -Wextra, y tal vez incluso -Wpedantic. Técnicamente, la conversión entre punteros a funciones y punteros a objetos (los punteros "normales"), incluyendo void*, no es válida, y probablemente se te muestre un warning, pero dudo que eso cause el problema, porque esas conversiones son tan comunes que los compiladores normalmente las admiten y generan código correcto.

GCC sí permite funciones anidadas, pero es una extensión al lenguaje específica de ese compilador y, llegados a ese punto, ya no estarías realmente programando en C sino en el dialecto GNU C.

Para algo en C estándar necesitas especificar qué es exactamente lo que esperas y por qué no usar una función normal. En la mayoría de los casos, este tipo de cosas son innecesarias y casi siempre hay mejores maneras de hacerlas. Sin más contexto, te diría que las formas obvias serían goto o setjmp/longjmp, pero está totalmente desaconsejado su uso, y tienen inconvenientes que casi siempre superan con mucho las posibles ventajas. Pero si explicas mejor lo que buscas, puede que haya alternativas mejores.