all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ken Brown <kbrown@cornell.edu>
Cc: 23771@debbugs.gnu.org, eggert@cs.ucla.edu
Subject: bug#23771: Eliminating compiler warnings
Date: Thu, 16 Jun 2016 18:14:37 +0300	[thread overview]
Message-ID: <83inx9cgiq.fsf@gnu.org> (raw)
In-Reply-To: <3f178870-9b99-8104-cb34-1967790436a5@cornell.edu> (message from Ken Brown on Wed, 15 Jun 2016 21:38:19 -0400)

> Cc: 23771@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
> From: Ken Brown <kbrown@cornell.edu>
> Date: Wed, 15 Jun 2016 21:38:19 -0400
> 
> > What warnings does that option produce?  I'm not sure I've seen any
> > warnings about addresses, but maybe I misunderstand the nature of the
> > warning.
> 
> Here's a typical example:
> 
> ../../master/src/menu.c: In function ‘digest_single_submenu’:
> ../../master/src/menu.c:46:30: warning: the address of ‘AppendMenuW’ 
> will always evaluate as ‘true’ [-Waddress]
>   # define unicode_append_menu AppendMenuW
>                                ^
> ../../master/src/menu.c:691:9: note: in expansion of macro 
> ‘unicode_append_menu’
>       if (unicode_append_menu)
>           ^

For this one, I'd suggest to make unicode_append_menu a variable in
the Cygwin build as well, and then do this:

  AppendMenuW_Proc unicode_append_menu = AppendMenuW;

> >> +#else  /* not HAVE_WINDOW_SYSTEM */
> >> +
> >> +_Noreturn void
> >> +decode_window_system_frame (Lisp_Object frame)
> >> +{
> >> +  error ("Window system is not in use");
> >> +}
> >> +
> >> +_Noreturn void
> >> +check_window_system (struct frame *f)
> >> +{
> >> +  error ("Window system is not in use");
> >> +}
> >> +
> >> +#endif	/* not HAVE_WINDOW_SYSTEM */
> >
> > What kind of warnings do you get without these changes?  I don't
> > understand why this is needed.
> 
> A build with no windows system yields these warnings:
> 
> ../../warnings/src/frame.c: In function ‘decode_window_system_frame’:
> ../../warnings/src/frame.c:119:1: warning: function might be candidate 
> for attribute ‘noreturn’ [-Wsuggest-attribute=noreturn]
>   decode_window_system_frame (Lisp_Object frame)
>   ^

How about making check_window_system compile in the no-X builds?

> >> --- a/src/conf_post.h
> >> +++ b/src/conf_post.h
> >> @@ -211,7 +211,7 @@ You lose; /* Emacs for DOS must be compiled with DJGPP */
> >>  extern void _DebPrint (const char *fmt, ...);
> >>  #  define DebPrint(stuff) _DebPrint stuff
> >>  # else
> >> -#  define DebPrint(stuff)
> >> +#  define DebPrint(stuff) {}
> >>  # endif
> >>  #endif
> >
> > Yuck!  Can we simply not use the "empty body" warning option?  When is
> > it important to flag an empty body of a function?
> 
> Here's a typical example:
> 
> Code like this:
> 
>    if (!f->output_data.w32->asked_for_visible)
>      DebPrint (("frame %p (%s) reexposed by WM_PAINT\n", f,
> 	       SDATA (f->name)));
> 
> leads to this warning (if EMACSDEBUG is not defined):
> 
> ../../warnings/src/w32term.c: In function ‘w32_read_socket’:
> ../../warnings/src/w32term.c:4613:28: warning: suggest braces around 
> empty body in an ‘if’ statement [-Wempty-body]
>             SDATA (f->name)));
>                              ^

One way of fixing this is to add those braces.

> But I'd be fine with just disabling this warning, at least for the w32 
> builds.

Right.





  reply	other threads:[~2016-06-16 15:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-15  2:04 bug#23771: Eliminating compiler warnings Ken Brown
2016-06-15 14:44 ` Eli Zaretskii
2016-06-16  1:38   ` Ken Brown
2016-06-16 15:14     ` Eli Zaretskii [this message]
2016-06-16 15:50       ` Paul Eggert
2016-06-21  3:11       ` Ken Brown
2016-06-22  1:12     ` Paul Eggert
2016-06-22  6:10       ` martin rudalics
2016-06-23  7:15         ` Paul Eggert
2016-06-22 14:04       ` Andy Moreton
2016-06-22 14:10         ` Ken Brown
2016-06-22 14:06       ` Ken Brown
2016-06-15 20:24 ` Richard Stallman
2016-06-16  1:41   ` Ken Brown

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83inx9cgiq.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=23771@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=kbrown@cornell.edu \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.