On Mon, Jun 2, 2014 at 3:02 PM, Paul Eggert wrote:
> Ben Walton wrote:
>>
>> With a new _GL_UNUSED_LABEL, which is cleaner than my patch, I'm less
>> inclined.
>
>
> Then please go with that. It's not a big deal either way.
Done. Updated patch sent.
Thanks
-Ben
--
-
Ben Walton wrote:
With a new _GL_UNUSED_LABEL, which is cleaner than my patch, I'm less
inclined.
Then please go with that. It's not a big deal either way.
On Sun, Jun 1, 2014 at 11:47 PM, Paul Eggert wrote:
> Ben Walton wrote:
>>
>> WIth your suggested followup
>> (prerequisite), I think that it's a better solution.
>
>
> Better yet, how about putting the goto-containing code into a subsdiary
> static function that can return rather than goto? That
On 06/02/2014 01:14 AM, Paul Eggert wrote:
> Pádraig Brady wrote:
>> Well the ; is needed in C++ but optional in C.
>> I was worried about users leaving out the ; by mistake
>> and not noticing in the normal case of compiling in C.
>
> But then the other case should be "# define _GL_UNUSED_LABEL ;
Another argument for omitting the semicolon is, suppose we add another
label-related attribute later? _GL_HOT, say? Then, 'lab: _GL_HOT
_GL_UNUSED_LABEL' would work, but 'lab: _GL_UNUSED_LABEL _GL_HOT' would
not, and users would have to remember to always put _GL_UNUSED_LABEL
last among all t
Pádraig Brady wrote:
Well the ; is needed in C++ but optional in C.
I was worried about users leaving out the ; by mistake
and not noticing in the normal case of compiling in C.
But then the other case should be "# define _GL_UNUSED_LABEL ;", no?
Otherwise a semicolon would be appended sometim
On 06/02/2014 12:53 AM, Paul Eggert wrote:
> Paul Eggert wrote:
>> Pádraig Brady wrote:
>>
>>> +# define _GL_UNUSED_LABEL _GL_UNUSED;
>>
>> Why is there a semicolon at the end of that macro definition?
>
> I removed it just now (since I was syncing to Emacs and I couldn't stand
> seeing the typo
Paul Eggert wrote:
Pádraig Brady wrote:
+# define _GL_UNUSED_LABEL _GL_UNUSED;
Why is there a semicolon at the end of that macro definition?
I removed it just now (since I was syncing to Emacs and I couldn't stand
seeing the typo there...).
Pádraig Brady wrote:
+# define _GL_UNUSED_LABEL _GL_UNUSED;
Why is there a semicolon at the end of that macro definition? It might
cause problems, no? _GL_UNUSED_LABEL is supposed to not affect the
semantics of the program, but with a semicolon there it could change things.
Ben Walton wrote:
WIth your suggested followup
(prerequisite), I think that it's a better solution.
Better yet, how about putting the goto-containing code into a subsdiary
static function that can return rather than goto? That'd be cleaner anyway.
On Sun, Jun 1, 2014 at 9:59 PM, Pádraig Brady wrote:
> On 06/01/2014 09:34 AM, Ben Walton wrote:
>> * Avoid possible compiler warnings/errors by defining the out label
>> only when it may be accessed.
>>
>> Signed-off-by: Ben Walton
>> ---
>>
>> Hi All,
>>
>> When building coreutils 8.22 on
On 06/01/2014 09:59 PM, Pádraig Brady wrote:
> On 06/01/2014 09:34 AM, Ben Walton wrote:
>> * Avoid possible compiler warnings/errors by defining the out label
>> only when it may be accessed.
>>
>> Signed-off-by: Ben Walton
>> ---
>>
>> Hi All,
>>
>> When building coreutils 8.22 on Solaris
On 06/01/2014 09:34 AM, Ben Walton wrote:
> * Avoid possible compiler warnings/errors by defining the out label
> only when it may be accessed.
>
> Signed-off-by: Ben Walton
> ---
>
> Hi All,
>
> When building coreutils 8.22 on Solaris with -Werror=unused-label, the build
> fails with:
>
* Avoid possible compiler warnings/errors by defining the out label
only when it may be accessed.
Signed-off-by: Ben Walton
---
Hi All,
When building coreutils 8.22 on Solaris with -Werror=unused-label, the build
fails with:
lib/rename.c: In function 'rpl_rename':
lib/rename.c:465:2: err
14 matches
Mail list logo
