RE: [PATCH] Factorize the two read_line functions present in gcov.c and input.c

[Bernd Edlinger]

> On 11/07/13 09:32, Dodji Seketeli wrote:
>
>> From the above, what I can say is that input.o was already linked with
>> gcov. But I think it's minimal enough to only drag libcpp and the
>> diagnostic subsystem.
>
> I disagree. While input.o was available to gcov, I don't think it was being
> pulled into the executable (if it was, I'd like to understand why). I think
> dragging in libcpp & diagnostics is a major bloat -- have you measured the
> before and after gcov text sizes?


I agree that this should be avoided. However both versions of read_line
need to be fixed eventually.

Just for the records, this is not only a theoretical issue for gcov:
The OOM error can also be reproduced in gcov.

The attached test.c has some dozends of comment lines:
//xx\0EOL

That are lines with text before and after the \0.
If compiled without -Wall, it will crash in gcov:


gcc -fprofile-arcs -ftest-coverage test.c
./a.out
gcov test
File 'test.c'
Lines executed:100.00% of 1
Creating 'test.c.gcov'

gcov: out of memory allocating 1677721600 bytes after a total of 135168 bytes


Bernd.                                    
//00EOL
//01EOL
//02EOL
//03EOL
//04EOL
//05EOL
//06EOL
//07EOL
//08EOL
//09EOL
//10EOL
//11EOL
//12EOL
//13EOL
//14EOL
//15EOL
//16EOL
//17EOL
//18EOL
//19EOL
//20EOL
//21EOL
//22EOL
//23EOL
//24EOL
//25EOL
//26EOL
//27EOL
//28EOL
//29EOL
//30EOL
//31EOL
//32EOL
//33EOL
//34EOL
//35EOL
//36EOL
//37EOL
//38EOL
//39EOL
//40EOL
//41EOL
//42EOL
int main() { }
// EOF