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.

Dado el tipo de error, lo que deberías postear es el contenido de SerialClass.h. Es casi seguro que ahí esté el problema. O cambia el parámetro de Serial::Serial a const char*, que de cualquier forma, independientemente de que compile o no, es lo correcto si quieres aceptar cadenas literales.

La forma en que funciona el sistema de diagnóstico y reporte de errores de Windows es algo compleja, y la información oficial está bastante dispersa, pero aquí se explica lo que se puede enviar cuando hay errores del sistema: https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/memory-dump-file-options

en Windows 10, el tipo de volcado predeterminado es el Automático, que es casi igual al de memoria del kernel.

Más interesante es lo que pasa cuando es una aplicación la que produce el error. De forma general se recogen datos parecidos a los de los errores de sistema: pila de llamadas, lista de módulos cargados y handles del proceso, estado de los registros, instrucción que provocó la excepción, etc. Lo llamativo en cuanto a la privacidad es que Windows 10 ya ni siquiera pregunta: con la configuración predeterminada, cuando un programa termina de manera inesperada, de forma automática y silenciosa se crea un reporte que es enviado a los servidores de Microsoft (a menos que el programa solicite que no se haga). Y el programa en cuestión puede pedir a Windows que anexe al reporte cosas adicionales como volcados de bloques específicos de memoria o archivos. Las empresas de software pueden registrar sus aplicaciones con Microsoft y así tener acceso a estos reportes, entre otras cosas. Si somos paranoicos, notaremos que, dado que es Windows el que recaba y envía los datos, esto permite que, sin siquiera acceder directamente a internet, los programas puedan enviar información más o menos arbitraria de manera indirecta... XD

Nah, la verdad es que exagero. El mecanismo es más complicado que esto, y aún si el programa solicita el anexo de datos extra, se requiere algún paso adicional para que sean realmente enviados. Y para acceder a esto, como decía, hace falta registrarse con Microsoft y proporcionar datos de contacto personales, de empresa, etc. Obviamente no es imposible falsificar esa información, pero es arriesgado y, como digo, no tan simple como pareciera, por lo que veo poco probable que pase. Y no es tan difícil saber si un programa está husmeando en directorios o archivos indebidos. De todas formas, esto puede ser una razón adicional para no ejecutar cualquier programa que se descarga uno de internet.

Es bueno ser precavido y tener un poco de paranoia, pero sin exagerar. Seguramente Microsoft recolecta más información de la estrictamente necesaria, pero yo no me alarmaría. A diferencia de Google o Facebook, ellos no son una empresa que dependa de la publicidad. Sus negocios principales, y que son los que más dinero le dejan por mucho, son servicios empresariales en la nube, suscripciones de Office y cosas por el estilo, y por las que la gente paga. Realmente no tiene un gran incentivo en la actualidad para espiar excesivamente a los usuarios (palabra clave: "excesivamente", porque yo creo que, en mayor o menor medida, la mayoría de las empresas lo hacen), arriesgándose a sanciones, multas y demandas, cuando la publicidad no es ni por mucho una de sus áreas esenciales.


No es así. Por lo menos una buena parte de lo que se envía sí que es información de diagnóstico que puede ser bastante útil para los desarrolladores. Es difícil saber exactamente qué datos se mandan, pero sí se sabe con precisión que incluye esto: información del hardware, consultas hechas en la barra de búsqueda de Windows, información de varias actividades de Windows (búsquedas de actualizaciones, por ejemplo), como el tiempo que tomaron, la fecha y hora, el resultado, códigos de error si los hay, etc., y creo que también la frecuencia con que ejecutas ciertas aplicaciones, aunque no estoy seguro de si esto sólo lo hace cuando eliges el envío de datos opcionales.

Además de lo anterior, cuando los reportes se generan en respuesta a un error de sistema o de alguna aplicación, hay bastantes cosas más que pueden ser enviadas, aunque esas ya no dependen totalmente de la configuración de datos de diagnóstico general, sino que influyen otros factores, pero no sé si también te interese saber sobre eso.

Difícilmente. Obviamente, todo eso ya lo había pensado cuando escribí: "no se me ocurre ninguna razón medianamente razonable o inteligente para haber borrado ése", por eso especifiqué lo de "razonable o inteligente".

Para empezar, ilegal no es. El usuario no preguntaba cómo conseguir cuenta premium gratuita, ni cómo entrar a cuentas ajenas, ni cómo acceder a una misma cuenta de Spotify desde dos dispositivos distintos simultáneamente, ni nada por el estilo. Lo único que quería era abrir dos instancias de la aplicación en su PC, con dos distintas cuentas, cosa que se puede hacer sin problemas desde el navegador, y desde la app de Android. Sospecho que la limitante en PC es más por cuestión técnica (muy poca gente querría esa funcionalidad, así que ¿para qué implementarla?), aunque no lo sé con certeza.

Por supuesto, tampoco atenta contra la privacidad de nada. Otra cosa muy distinta es que pueda ir en contra de los términos de uso, lo cual no sé, pero dudo mucho que sea el caso (no tendría sentido), y un vistazo rápido a los TOS de Spotify no muestra ninguna prohibición o restricción que remotamente se relacione con esto. De cualquier forma, sería bastante incongruente borrar un tema por eso, cuando, por ejemplo, los propios administradores les pasan a los usuarios links a activadores de Windows y Office, y hay una colección muy grande de manuales (muchos de los cuales prohíben expresamente la distribución de copias) que incluso están alojados en los servidores de elhacker.

Completamente de acuerdo.

También una cosa sería borrar temas sin respuesta. Ahí no creo que importe mucho, pero si el tema ya tiene respuestas...

Porque justamente eso pasó con un tema donde se preguntaba cómo abrir dos instancias de Spotify en PC, y ayer lo borraron. Digo, yo no lo creé, pero sí respondí, y al menos otros tres usuarios también dieron sugerencias, y ahora todo eso se fue a la basura. ¿Qué sentido tiene entonces tomarse el tiempo de responder preguntas si van a borrar los temas por borrarlos? Porque no se me ocurre ninguna razón medianamente razonable o inteligente para haber borrado ése.

Es porque ese manual está muy obsoleto (además de ser muy malo).

En el C++ estándar (desde 1998, para que veas lo obsoleto del manual) ostream está dentro del namespace std. Para que te compile, debes escribir std::ostream