From: "Philip Oakley" <philipoakley@iee.org>
To: "Stefan Beller" <sbeller@google.com>,
"Junio C Hamano" <gitster@pobox.com>
Cc: "Marc Branchaud" <marcnarc@xiplink.com>,
"Ramsay Jones" <ramsay@ramsayjones.plus.com>,
"Duy Nguyen" <pclouds@gmail.com>,
"Git List" <git@vger.kernel.org>
Subject: Re: /* compiler workaround */ - what was the issue?
Date: Mon, 9 May 2016 20:40:22 +0100 [thread overview]
Message-ID: <9836AC86AA754C27AFD5D87519DF1402@PhilipOakley> (raw)
In-Reply-To: CAGZ79kby0Z1FMUT-w8h=YfRxsmyXaiE2pA_VoJ0g9wn0Mzk2Wg@mail.gmail.com
From: "Stefan Beller" <sbeller@google.com>
> On Fri, May 6, 2016 at 12:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Marc Branchaud <marcnarc@xiplink.com> writes:
>>
>>> On 2016-05-06 02:54 PM, Junio C Hamano wrote:
>>>>
>>>> I wonder if can we come up with a short and sweet notation to remind
>>>> futhre readers that this "initialization" is not initializing but
>>>> merely squelching warnings from stupid compilers, and agree to use
>>>> it consistently?
>>>
>>> Perhaps
>>>
>>> #define COMPILER_UNINITIALIZED_WARNING_INITIALIZER 0
>>>
>>> or, for short-and-sweet
>>>
>
> /* Here could go a longer explanation than the 4 character
> define :) */
>>> #define CUWI 0
>>>
>>> ?
>>>
>>> :)
>>
>> I get that smiley.
>>
>> I was hinting to keep the /* compiler workaround */ comment, but
>> in a bit shorter form.
>> --
For some background, I found $gmane/169098/focus=169104 which covers some of
the issues (the focused msg is one from Junio). Hannes then notes
($gmane/169121) that the current xx = xx; could be seen as possible
undefined behaviour - perhaps one of those 'no good solution' problems.
Perhaps a suitable name...
#define SUPPRESS_COMPILER_UNINITIALIZED_WARNING 0
/* Use when some in-use compiler is unable to determine if the variable is
used uninitialized, and no good default value is available */
Though, where best to put it?
--
Philip
next prev parent reply other threads:[~2016-05-09 19:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AA5B2B1715BAF7438221293187A417A7BDE9D11D@desmdswms002.des.grplnk.net>
2016-05-05 20:48 ` /* compiler workaround */ - what was the issue? Philip Oakley
2016-05-05 21:41 ` Junio C Hamano
2016-05-06 10:17 ` Duy Nguyen
2016-05-06 13:15 ` Philip Oakley
2016-05-06 18:05 ` Ramsay Jones
2016-05-06 18:33 ` Philip Oakley
2016-05-06 18:54 ` Junio C Hamano
2016-05-06 19:30 ` Marc Branchaud
2016-05-06 19:57 ` Junio C Hamano
2016-05-06 20:01 ` Stefan Beller
2016-05-09 19:40 ` Philip Oakley [this message]
2016-05-09 19:49 ` Randall S. Becker
2016-05-06 20:28 ` Marc Branchaud
2016-05-06 20:21 ` Ramsay Jones
2016-05-06 21:17 ` Ramsay Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9836AC86AA754C27AFD5D87519DF1402@PhilipOakley \
--to=philipoakley@iee.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=marcnarc@xiplink.com \
--cc=pclouds@gmail.com \
--cc=ramsay@ramsayjones.plus.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).