Re: [PATCH v2] Implement pahole-like 'ptype /o' option

[Pedro Alves <palves@redhat.com>]

On 12/11/2017 09:07 PM, Sergio Durigan Junior wrote:

>>> This is actually on purpose.  If I indent the line, it will have more
>>> than 80 chars.  I believe this is a well known method for avoiding this
>>> problem...?
>>
>> I am not aware of that.  In this case I would put the parameter list on the next,
>> I'm not sure if it's 100% GNU-style approved, but nobody complained when I did it
>> so far :)
>>
>> static void
>> print_spaces_filtered_with_print_options
>>   (int level, struct ui_file *stream, const struct type_print_options *flags);
>>
>> It helps with long function names.  In this case, I would probably just drop the
>> "struct" to save a few chars, because C++.
> 
> Fair enough.  I use this trick for function prototypes, but not for the
> definitions.

Simon's format is what I've been using for a long while too.

>> But I don't mind it, it just stuck out as a little inconsistency.
> 
> I don't see the inconsistency.
> 
> If a field is inside a struct, it has its offset *and* size printed.  No
> matter if the field is an int, another struct, or an union.
> 
> If a field is inside an union, it has only its size printed.
> 
> In the case above, it makes sense to have the offsets printed for the
> fields inside the two structs (inside the union), because there might be
> holes to report (well, one can argue that it doesn't matter if there are
> holes or not in this case, because if the other struct is bigger then
> the union size will stay the same).  However, it doesn't make sense to
> print the offsets for the two structs themselves, because they are
> members of the union.
> 
> I hope it makes more sense now.

But why do we need the special case?  Does it help anything?
So far, it seems it only added confusion.

The option is "/o" for "print offsets".  Why not print offsets always?

BTW, shouldn't the documentation in the manual include an example
of GDB's output?

Thanks,
Pedro Alves