This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fixes for a small number of compiler warnings

On Tue, Mar 31, 2015 at 8:48 PM, Alan Modra <> wrote:
> On Tue, Mar 31, 2015 at 08:32:35PM -0700, H.J. Lu wrote:
>> On Tue, Mar 31, 2015 at 8:27 PM, Alan Modra <> wrote:
>> > On Tue, Mar 31, 2015 at 07:53:36PM -0700, H.J. Lu wrote:
>> >> This becomes a regression with the older GCC.
>> >
>> > Yes.  I'd rather cause that than have warnings with more recent gcc
>> > versions..  I also agree that we shouldn't worry too much about
>> > compilers other than gcc, and I know that self-assignment is something
>> > that C++ programmers need to worry about which is no doubt why the
>> > warning is on for Clang.
>> >
>> > I did consider just reverting the previous patch, but fixing a warning
>> > with a self-assignment just looks horrible to me, particularly when
>> > the warning is about an uninitialized variable.  I mean, it looks to
>> > me that a self-assignment actually creates an uninitialized variable
>> > access at the abstract level, when there wasn't one there before!
>> For this particular case, self-assignment causes no harm since
>> the variable will be initialized.
> I didn't say there was any harm, just that I dislike the style and why
> I dislike it.
>> Will
>> struct bfd_link_hash_entry ehdr_start_save = { 0 };
>> for all compilers?

How about something like

struct bfd_link_hash_entry

We define it to self-assign only for those affect GCCs.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]