Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: John Gilmore <gnu@toad.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: tromey@redhat.com, gdb@sourceware.org
Subject: Re: C99?  No, portability.
Date: Wed, 17 Jul 2013 08:11:00 -0000	[thread overview]
Message-ID: <201307170811.r6H8BagN018382@new.toad.com> (raw)
In-Reply-To: <201307162122.r6GLMlMx012078@glazunov.sibelius.xs4all.nl>

> > So, I'd like to propose we allow the use of C99 in gdb.  In particular I
> > think we ought to require a C99 preprocessor -- enabling this particular
> > patch to go in and also allowing the use of "//" comments.
> 
> Perhaps it is time to move on and start requiring a C99 compiler for GDB.

Mark said it correctly.  This change would "require" a C99 compiler.
Not just "allow the use of C99 in GDB".

I recommend that you NOT break compatability with older compilers for
gratuitous reasons.  For example, I still run systems based on Red Hat
7.3, which use gcc-2.96.  I can still compile modern GDB's on that
system.  (With the few portability patches below :-).)

If you switched to requiring C99 in new GDB releases, I could still
probably compile a modern GDB -- I'd just have to edit a hundred more
places where you've made use of some new construct where an old one
would do just as well.  And of course you wouldn't take my portability
patches back.  If you'd allow old-system GDB users to fix a C99 GDB so
that it didn't require C99 any more, what would be the point of
switching to requiring C99?

The particular patch that Tom pointed out would remove the use of
GCC-specific vararg CPP macros from gdbserver.  Fixing that would be a
good thing for portability.  I do suggest fixing it -- not by
requiring C99, but by fixing all the calls to those couple of macros
so that they don't require vararg macros, since you can't do vararg
macros portably.  Then when you were done, GDB would be even more
portable, rather than less portable.

	John

./dwarf2.c: In function `_bfd_dwarf2_cleanup_debug_info':
./dwarf2.c:3604: parse error before `struct'
./dwarf2.c:3609: `each' undeclared (first use in this function)

diff -ru gdb-7.5/bfd/dwarf2.c gdb-7.5-for-rh7.3/bfd/dwarf2.c
--- gdb-7.5/bfd/dwarf2.c	Wed May 16 06:57:11 2012
+++ gdb-7.5-for-rh7.3/bfd/dwarf2.c	Wed Jul 17 00:35:42 2013
@@ -3600,7 +3600,7 @@
 void
 _bfd_dwarf2_cleanup_debug_info (bfd *abfd, void **pinfo)
 {
-  struct dwarf2_debug *stash = (struct dwarf2_debug *) *pinfo;;
+  struct dwarf2_debug *stash = (struct dwarf2_debug *) *pinfo;
   struct comp_unit *each;
 
   if (abfd == NULL || stash == NULL)

elflink.c: In function `elf_link_add_object_symbols':
elflink.c:4730: warning: `idx' might be used uninitialized in this function

diff -ru gdb-7.5/bfd/elflink.c gdb-7.5-for-rh7.3/bfd/elflink.c
--- gdb-7.5/bfd/elflink.c	Mon Jul  9 01:17:34 2012
+++ gdb-7.5-for-rh7.3/bfd/elflink.c	Wed Jul 17 00:38:46 2013
@@ -4729,6 +4729,7 @@
 	  bfd_vma vlook;
 	  size_t i, j, idx;
 
+	  idx = 0;
 	  hlook = weaks;
 	  weaks = hlook->u.weakdef;
 	  hlook->u.weakdef = NULL;


gdbreplay.c: In function `expect':
gdbreplay.c:372: warning: `fromgdb' might be used uninitialized in this function

diff -ru gdb-7.5/gdb/gdbserver/gdbreplay.c gdb-7.5-for-rh7.3/gdb/gdbserver/gdbreplay.c
--- gdb-7.5/gdb/gdbserver/gdbreplay.c	Wed Jan  4 00:17:23 2012
+++ gdb-7.5-for-rh7.3/gdb/gdbserver/gdbreplay.c	Wed Jul 17 00:56:59 2013
@@ -369,7 +369,7 @@
 expect (FILE *fp)
 {
   int fromlog;
-  int fromgdb;
+  int fromgdb = 0;
 
   if ((fromlog = logchar (fp)) != ' ')
     {

cc1: warnings being treated as errors
tracepoint.c:848: warning: `used' attribute directive ignored

diff -ru gdb-7.5/gdb/gdbserver/tracepoint.c gdb-7.5-for-rh7.3/gdb/gdbserver/tracepoint.c
--- gdb-7.5/gdb/gdbserver/tracepoint.c	Sat Apr 28 23:28:30 2012
+++ gdb-7.5-for-rh7.3/gdb/gdbserver/tracepoint.c	Wed Jul 17 00:59:07 2013
@@ -845,7 +845,7 @@
 /* The linked list of all tracepoints.  Marked explicitly as used as
    the in-process library doesn't use it for the fast tracepoints
    support.  */
-IP_AGENT_EXPORT struct tracepoint *tracepoints ATTR_USED;
+IP_AGENT_EXPORT struct tracepoint *tracepoints /* ATTR_USED makes -Werror fail */;
 
 #ifndef IN_PROCESS_AGENT
 

xml-support.c: In function `gdb_xml_fetch_external_entity':
xml-support.c:513: storage size of `status' isn't known
xml-support.c: In function `gdb_xml_use_dtd':
xml-support.c:562: warning: implicit declaration of function `XML_UseForeignDTD'
xml-support.c:562: `XML_TRUE' undeclared (first use in this function)
xml-support.c:562: (Each undeclared identifier is reported only once
xml-support.c:562: for each function it appears in.)
xml-support.c: In function `gdb_xml_parse':
xml-support.c:579: storage size of `status' isn't known

diff -ru gdb-7.5/gdb/xml-support.c gdb-7.5-for-rh7.3/gdb/xml-support.c
--- gdb-7.5/gdb/xml-support.c	Wed Jan  4 00:27:58 2012
+++ gdb-7.5-for-rh7.3/gdb/xml-support.c	Wed Jul 17 00:54:44 2013
@@ -510,7 +510,7 @@
   struct gdb_xml_parser *parser = XML_GetUserData (expat_parser);
   XML_Parser entity_parser;
   const char *text;
-  enum XML_Status status;
+  int status;
 
   if (systemId == NULL)
     {
@@ -558,12 +558,14 @@
   XML_SetExternalEntityRefHandler (parser->expat_parser,
 				   gdb_xml_fetch_external_entity);
 
+#if 0  /* I'm not sure what to do here.  No decl for this function.  */
   /* Even if no DTD is provided, use the built-in DTD anyway.  */
   err = XML_UseForeignDTD (parser->expat_parser, XML_TRUE);
   if (err != XML_ERROR_NONE)
     internal_error (__FILE__, __LINE__,
 		    _("XML_UseForeignDTD failed: %s"),
 		    XML_ErrorString (err));
+#endif
 }
 
 /* Invoke PARSER on BUFFER.  BUFFER is the data to parse, which
@@ -576,7 +578,7 @@
 int
 gdb_xml_parse (struct gdb_xml_parser *parser, const char *buffer)
 {
-  enum XML_Status status;
+  int status;
   const char *error_string;
 
   gdb_xml_debug (parser, _("Starting:\n%s"), buffer);



  parent reply	other threads:[~2013-07-17  8:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16 20:51 C99 Tom Tromey
2013-07-16 21:23 ` C99 Mark Kettenis
2013-07-16 21:40   ` C99 Doug Evans
2013-07-17 20:48     ` C99 Mark Kettenis
2013-07-17 21:12       ` C99 Doug Evans
2013-07-17  8:11   ` John Gilmore [this message]
2013-07-17 22:38     ` C99? No, portability Doug Evans
2013-07-18 15:27       ` John Kearney
2013-07-19 17:39         ` Doug Evans
2013-07-18  6:54   ` C99 Yao Qi
2013-07-17  3:49 ` C99 Eli Zaretskii
2013-07-17 17:54   ` C99 Doug Evans
2013-07-18  2:47     ` C99 Yao Qi
2013-07-18  6:46       ` C99 Doug Evans

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=201307170811.r6H8BagN018382@new.toad.com \
    --to=gnu@toad.com \
    --cc=gdb@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=tromey@redhat.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox