Closed frankier closed 5 years ago
Just to note, there are multiple reasons why it may work by coincidence. For example, if the compiler decides to align or pack the memory locations for variables in a particular way, the upper bits of the long may end up being zero. However, treating a memory location with a type with one size as another type with another size is undefined behavior.
Fixed by #16 as well.
This prevents a segfault on my machine: The problem is that 'long' are bigger than ints and the extra memory may not be zero.
My system (more information available upon request): gcc version 6.3.0 20170415 (Debian 6.3.0-14) Description: Debian GNU/Linux 9.0 (stretch) Linux kagh-local 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 (2017-03-30) x86_64 GNU/Linux
Steps to reproduce segfault: gdb ./trec_eval/trec_eval (gdb) run -q -m official adhoc-news/assessments/assessments2004/qrels_EN results201 Starting program: /home/frankier/edutmp/ir/lab2/trec_eval/trec_eval -q -m official adhoc-news/assessments/assessments2004/qrels_EN results201
Program received signal SIGSEGV, Segmentation fault. 0x0000555555559520 in main (argc=6, argv=0x7fffffffe1a8) at trec_eval.c:339 339 if (MEASURE_MARKED(te_trec_measures[m])) {
(the files are from a University assignment and can be provided on request)