franvinas / taller1-tp0 Goto Github PK

¿Por qué no se detiene ahi?

Esto mas que nada es nitpicking, ya que lo vas a ver a medida que veamos tda y objetos en las clases (y cuando hagamos los tps en C++), pero por lo general el destructor libera recursos que se piden en el constructor.

El TP esta bastante bien, hay algunas cosas para corregir. Esta aprobado, pero si queres hacete la reentrega para subir unos puntitos mas.

Si bien es cierto strncpy no resuelve el error asi como la escribiste, pasando n como el tamaño del string que recibis por stdin, estaría mal utilizada y esto es muy importante que lo veas. El overflow se podria dar igual y de hecho el compilador tira ese error que vos remarcas.
Además, hay varios problemas acá. No solo esta mal utilizada memcpy en primer lugar, sino que si reemplazamos por strncpy, tendríamos el problema de que no importa el tamaño del buffer que reservemos en el stack, siempre puede venir un filename mas grande que lo que se puede guardar en este buffer y por ende el filename quedaria truncado. Fallariamos al abrir el archivo

Si bien comentas un poco mas arriba que depende de la arquitectura (¿Y de qué más depende? Repasar primera clase) quiero reforzar que esto no siempre es así.

Tu respuesta es del estilo "el debugger no se detiene porque no se detiene". La realidad es que el debugger no se detiene en esa linea (la que suma a la cantidad de palabras) porque no se cumple la condición de entrada a ese scope, encontrar un delim_word en la palabra actual. Como el archivo no contiene ningun delim_word (salto de linea por ejemplo), el programa no lo detecta como palabra. La correción que se agrega en el paso 6 resuelve esto agregando un nuevo estado de lectura. Si se sigue leyendo y se encontro el eof antes de un delim_word, se cuenta como palabra.