Re: [PATCH 3/8] Simplify representation of locations of a block.

[Martin Sebor <msebor@gmail.com>]

On 04/28/2017 05:47 AM, Nathan Sidwell wrote:
> On 04/21/2017 10:02 AM, marxin wrote:
>> gcc/ChangeLog:
>>
>> 2017-04-26  Martin Liska  <mliska@suse.cz>
>>
>>     * gcov.c (struct block_location_info): New struct.
>>     (process_file): Fill up the new structure.
>>     (read_graph_file): Replace usage of encoding by the newly added
>>     struct.
>>     (add_line_counts): Likewise.
>>     (accumulate_line_counts): Remove usage of the union.
>>     (function_info::function_info): New function.
>>     (function_info::~function_info): Likewise.
>>     (process_file): Call delete instead of release_function.
>>     (release_function): Release the function.
>>     (release_structures): Call delete instead of release_function.
>>     (solve_flow_graph): Replace usage of num_blocks.
>>     (find_exception_blocks): Likewise.
>>     (output_lines): Fix GNU coding style.
>
>> diff --git a/gcc/gcov.c b/gcc/gcov.c
>> index 63f6a75f1af..7400cdee110 100644
>> --- a/gcc/gcov.c
>> +++ b/gcc/gcov.c
>> @@ -114,6 +114,16 @@ typedef struct arc_info
>>     struct arc_info *pred_next;
>>   } arc_t;
>>   +struct block_location_info
>
> /* needs comment.  */
>
>
>
>> @@ -427,9 +429,31 @@ static void output_lines (FILE *, const source_t *);
>>   static char *make_gcov_file_name (const char *, const char *);
>>   static char *mangle_name (const char *, char *);
>>   static void release_structures (void);
>> -static void release_function (function_t *);
>>   extern int main (int, char **);
>>   +function_info::function_info ()
>> +{
>> +  memset (this, 0, sizeof (*this));
>
> EW.  ok with a comment about function_info's c++11's PoDness.

Unless it's some other kind of vector, the patch adds a vector
member to the class, which makes it not a PoD.(*)

In addition, it would make the class ever so slightly safer to
use if it were made non-copyable (by declaring its copy ctor
private).  Otherwise, accidentally creating a copy of an object
of the type could lead to a double free in the newly added dtor.

Martin

[*]  Strictly speaking using memset to initialize pointers to
null isn't guaranteed to work on targets where a null pointer
isn't all bits clear.  I don't know if GCC is meant to build
on such targets but the code would be cleaner (albeit more
verbose) if it defeault-initialized each member in the ctor
initializer list.