Buenas,

Por un lado, lo de NULL. malloc devuelve NULL si no puede conseguir ese espacio de memoria. Comprobar que malloc no devuelva NULl es una técnica bastante "defensiva" ante errores por memoria (que no haya memoria, que se intente reservar una cantidad contigua de memoria demasiado grande...). En mi opinión, no es común, salvo que sea un código profesional. personalmente te diría que en tu código, de momento, no hagas esas comprobaciones. Son casos muy específicos. Habrá quien opine diferente anyway.

Sobre lo de malloc en Lista, no sé si te sigo bien: Para cualquier estructura que se quiera tener en memoria (en el heap), hay que reservarle memoria. La lista enlazada está compuesta de 2 tipos de estructuras: La lista en sí (lista), y sus elementos (Elemento). Cada vez que se crea una de estas estructuras, hay que reservar con malloc. En caso de Lista, se hará 1 vez por lista que se cree. En casod e Elemento, 1 vez por cada Elemento (Lo que se ve en ins_en_lista_vacia). De hecho, en ins_en_lista_vacia reserva 2 veces: 1 para el Elemento, y otra para el dato que guarda dentro (el char*).

No sé si esto responde bien a tu pegunta 👀

Reemplazar los tipos de los parametros por punteros a esos tipos, poder se puede, y por lo general, no debería fallar, pero tiene algunas complicaciones:
1. En la función habría que asegurarse (o dejar claro), que no puede recibir un nullptr o un puntero inválido. Para asegurar esto suele ser más visual pasar parámetros por referencia en vez de un puntero.
2. Pasar un puntero a int es tan costoso o más que pasar un int. Copiar un int o copiar un puntero, suele ser idéntico (ambos son tipos de dato entero, y el tamaño suele ser el mismo). Con lo cual, rara vez se gana nada, es raro ver un puntero a const int como parámetro, la verdad (lo mismo con cualquier otro tipo entero o float/double).
3. La norma general: usar cada cosa en su momento. Por muy grande que sea un programa, sus funciones son pequeñas, y cuanto más precisas sean sus definiciones, mejor. Es decir, si una funcion sum(a, b) necesita 2 enteros, pide 2 enteros, no 2 punteros, porque pedir punteros complica el uso de la función, y puede dar a pensar que la función haga otras cosas (¿Por qué pediría un puntero si no?). En caso de clases que no queramos copiar, por el motivo que sea (rendimiento, no se pueda copiar, etc etc), entonces pasar por referencia (const Class&) suele ser más efectivo.

Nota: Lo de paso por referencia es un tema de C++, no C. Si estás trabajando con C, ignora lo del paso por referencia: es poco más que una "utilidad" para facilitar el uso de punteros

La mejor opción creo yo sería pedirle al soporte del juego explícitamente que envien algo a tu correo secndario, no creo que tengan problema con ello.
Si no es posible, pues lo que dice Serapis. Ten en cuenta también que una de las cosas más peligrosas que puedes tener es correos registrados a los que no tienes acceso. En cuanto tengas la mínima idea de que puedes perder acceso a un correo (o número de teléfono), cambialo en todas las cuentas que puedas recordar. Y sobre todo, en las importantes

Buenas!

Como norma general, no te compliques, y separa los procesos lo más posible: Cuando meta el nombre, recorres la lista para ver si existe.
Si existe, se lo pones, para que ponga otro o vuelva al menú.
Si no existe, lo añades (o sigues pidiendo datos).

Hace tiempo que no trabajo con WinAPI en tema de ventanas, pero:
Si en vez de:

Pones:

Y en burbujas xD
No creo que la normalidad por la existencia de este virus entre los humanos deba cambiar de lo que era antes. Hay montones de virus, bacterias y demás patógenos y no andamos todos con mascarilla.
Y si dicen que es que "en China ya es el estandar", que recuerden que en China lo es principalmente por la contaminación, que yo sepa

¿En serio?
No hablo de alexbujaan, pero tened en cuenta que la mayoría de estudiantes de FP no se acercan a ese nivel

En parte diría que es un poco lo que le pasó a Windows Phone. Por potente que sea, si la gente sigue usando android en vez de ayudar a poblar Windows Phone, acaba muriendo y acabamos como acabamos.
Aquí lo mismo. Mientras se siga usando terminal para todo, mientras nadie se moleste en hacer interfaces, seguiremos igual: nadie disfrutará de las ventajas de una GUI.

Y LCD para una placa LCD xD

Whatever. A qué te refieres "que se parezca a programar C de Arduino en C#".
¿Qué quieres que se parezca? ¿Quieres que tu programa C# sea un una llamada a setup y llamadas a loop?
Si es eso, pues lo que tienes hecho e lo que hace, no entiendo. Tampoco entiendo la finalidad.

"...a menos que sea para cosas que las terminales no pueden reproducir por sus evidentes limitaciones" xD

Una terminal es una "GUI", no olvidemos. Una GUI con limitaciones.
Si partimos de ese punto, creo que cualquier exaltación de una terminal frente a otra interfaz gráfica es absurda.
Lo mismo que se hace escribiendo un comando, se puede hacer pulsando una tecla, o con un click, o ambas a la vez.

Al final la evolución de las consolas ha llevado a poner parche sobre parche para que alcancen las habilidades de una GUI. Aplicaciones que capturan los clicks en la consola, aplicaciones que se hacen con el control de la ventana de la consola... ¿Qué es una terminal a día de hoy? Solo me falta una app que dibuje winforms encima de la consola y que la gente diga "guao las posibilidades de una consola" xD