Fix the following two gcc warnings:
elfio/elfio_section.hpp:50:36: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
const size_t get_stream_size() const
^
elfio/elfio_segment.hpp:99:23: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
get_stream_size() const
Fix crash b82f05b0b25c8fdc98480e6d76b6d5f9164ae2bc
Running: crash-b82f05b0b25c8fdc98480e6d76b6d5f9164ae2bc
==2850==WARNING: AddressSanitizer failed to allocate 0x400000004000001 bytes
==2850==AddressSanitizer's allocator is terminating the process instead of returning 0
==2850==If you don't like this behavior set allocator_may_return_null=1
==2850==AddressSanitizer CHECK failed: /home/alvaro/tools/llvm/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:22
1 "((0)) != (0)" (0x0, 0x0)
The existing ELF file was somehow seriously broken.
It's now replaced with the file generated by the current code of
ELFio, which seems to be working correctly.
So the test now serves as a regression test for future
changes.
After loading, the data model in memory should resemble the original ELF file as closely as possible,
so that ELF viewers based on elfio will print out the original values, not the calculated ones.
Fix the following MSVC compiler warning:
elfio/elfio_note.hpp(77): warning C4267: 'initializing' : conversion from 'size_t' to 'ELFIO::Elf_Word', possible loss of data
by changing the type of max_name_sizei to Elf_Xword, as
note_secton->get_size() returns Elf_Xword and note_start_positions also
contains members of type Elf_Xword.
Don't cast away const qualifiers when accessing const data (e.g. section
data). This fixes the warnings such as the following when compiling with
GCC and the -Wcast-qual flag set:
warning: cast from type ‘const char*’ to type ‘ELFIO::Elf_Word* {aka unsigned int*}’ casts away qualifiers [-Wcast-qual]
Previously, when assigning 'name' as a string, it's length was specified
using the full length of 'namesz'. However, this length includes the
trailing '\0' of the underlying char[]. This ultimately causes the C++
string that is created to (incorrectly) contain the '\0' character as
well. This leads to problems where e.g. the following will return false,
even when 'name' itself actually contains the string "GNU\0":
if (name == "GNU") {
return true;
}
return false;
To fix this, we should only include the length of the string minus the
trailing '\0'.
