GitLab

The C character IO functions use an int for most operations, so
the type should be int for fgetc.

And the variable 'c' is reused to store the strlen() result.
Using a char type for strlen resulted in negative values whenever
a header line was longer than 127 bytes.

Here is a sample header line that caused problems:
x-microsoft-antispam-message-info: aybxZFQCLkTSg3dcgJ5/htFKWNjG+YSDDv+nSqJhvcMwb2hnzVKN1KQn0G0vxYRF7D1aWmkCcHUBLLWq/szFtrbKQ3BvDyr8nRMpr8jVkfWPpXt2np7eZDBBm4pU/TvGa+D8n+YUALZRs+9JliL3TzP8d2LRFDWhGKAQXl/FXwpzBq8mv+hxIiUYBHn0IxdJA1gJIxAZms1tqzec9XLV8sLrPDL0Hu2rHnGbCJLIphSC0abIOH1VTEEdzkbXhS8aSk6636GkCI1f2fN9PVNMj9uWzfIM1gSOeJyro6lQxREwwLMqnLGsf44OEKsqfCsh3yrOixdSBMWx09f3xJVgQBQOovwLCF7INvX6Oexzd8eA8YoHGp/01qVP4cPdd7W2TbxFlK8nMFmjuXdCyw/4If+dJu+uKpMQ2vh69jR7XWg=

After that, 'c' was negative and resulted in reads and writes into
unallocated memory and finally a segmentation fault.

This reverts commit 50f6c43a.

Build GTK+ 2 only, for now.

It was creating yparts with begin=0 and end==previous_part_begin with
multipart files. It should start from 1 and next part from previous end
+ 1.

NZB files which have empty segment lists crash pan (up to 0.144),
for me typically at the assertion on the last line of
Parts :: set_parts (around parts.cc line 237).

The problem is that "mc.parts" is not re-initialised for the new
list of segments if the first segment is not seen, depending on
the position in the file you will either get an incompletely
constructed PartBatch used (PartBatch relies on a default
constructor so packed_mids_len doesn't get initialised) or an
old list of segments could get re-used.

The problem is the scope of the return value from data.get_servers()
which is a std::set of Quarks

The temporary used for this value goes out of scope at the end of
the statement containing it - within the for loop control
statement - it is not in scope in the loop body.

The result is that later dereferencing the iterator on line 1158
accesses memory which has been returned to the heap.