Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "André Pönitz" <apoenitz@trolltech.com>
To: gdb-patches@sources.redhat.com
Subject: Re: gdb sources
Date: Fri, 19 Sep 2008 14:13:00 -0000	[thread overview]
Message-ID: <200809191612.23617.apoenitz@trolltech.com> (raw)
In-Reply-To: <20080912153534.GA13672@caradoc.them.org>

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

On Friday 12 September 2008 17:35:34 Daniel Jacobowitz wrote:
> On Fri, Sep 12, 2008 at 05:12:50PM +0200, André Pönitz wrote:
> > [...]
> > (2) Most of the "strings" in gdb are "char *", even if they are
> > conceptionally "const char *" (i.e. coming from literal, or not
> > intended to be changed). Why? In some places "const" is also
> > used, so the reason can't be "gdb supports compilers that
> > don't know about 'const'". Is it "just legacy"? If so, would patches
> > replacing "char *" by "const char *" if appropriate be welcome?
> 
> Yes, constifying patches are welcome.  It's just that gdb _used_ to
> support compilers that didn't know const, and may even predate
> const in places.

Ok. Something tiny attached for starters. It is as harmless as it can be.
I hope this is uncontroversial, but before going further into this
direction I have two related questions:

1. How would the prefered way to call, say,  xfree on a 'conceptionally const
char *' item look like? Are casts to non-const (void *) acceptable here?

2. Recording every such change in the ChangeLog basically duplicates
the work. Are there any shortcuts available/acceptable?

Andre'

[-- Attachment #2: 1 --]
[-- Type: text/x-diff, Size: 2958 bytes --]

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.9826
diff -r1.9826 ChangeLog
0a1,15
> 
> 2008-09-19  Andre Poenitz  <apoenitz@trolltech.com>
> 
> 	* symfile.c (allocate_symtab): Accept a const argument.
> 	* symfile.c (allocate_psymtab): Likewise.
> 	* symfile.c (free_named_symtabs): Likewise.
> 	* symfile.c (deduce_language_from_filename): Likewise.
> 
> 	* symfile.h (allocate_symtab): Update prototype.
> 	* symfile.h (allocate_psymtab): Likewise.
> 	* symfile.h (free_named_symtabs): Likewise.
> 	* symtab.h (deduce_language_from_filename): Likewise.
> 
> 	* i386-tdep.c (i386_analyze_stack_align): Fix typo in comment.
> 
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.266
diff -r1.266 i386-tdep.c
787c787
<   /* Rigister can't be %esp nor %ebp.  */
---
>   /* Register can't be %esp nor %ebp.  */
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.215
diff -r1.215 symfile.c
1547c1547
< 	  /* Make C the default language */
---
> 	  /* Make C the default language.  */
2688c2688
< deduce_language_from_filename (char *filename)
---
> deduce_language_from_filename (const char *filename)
2691c2691
<   char *cp;
---
>   const char *cp;
2717c2717
< allocate_symtab (char *filename, struct objfile *objfile)
---
> allocate_symtab (const char *filename, struct objfile *objfile)
2741c2741
< allocate_psymtab (char *filename, struct objfile *objfile)
---
> allocate_psymtab (const char *filename, struct objfile *objfile)
2949c2949
< free_named_symtabs (char *name)
---
> free_named_symtabs (const char *name)
3055c3055
< 		      struct section_offsets *section_offsets, char *filename,
---
> 		      struct section_offsets *section_offsets, const char *filename,
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.48
diff -r1.48 symfile.h
206c206
< extern struct symtab *allocate_symtab (char *, struct objfile *);
---
> extern struct symtab *allocate_symtab (const char *, struct objfile *);
208c208
< extern int free_named_symtabs (char *);
---
> extern int free_named_symtabs (const char *);
252c252
< 						    char *, CORE_ADDR,
---
> 						    const char *, CORE_ADDR,
302c302
< extern struct partial_symtab *allocate_psymtab (char *, struct objfile *);
---
> extern struct partial_symtab *allocate_psymtab (const char *, struct objfile *);
Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.131
diff -r1.131 symtab.h
1277c1277
< extern enum language deduce_language_from_filename (char *);
---
> extern enum language deduce_language_from_filename (const char *);

       reply	other threads:[~2008-09-19 14:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200809121713.09226.apoenitz@trolltech.com>
     [not found] ` <20080912153534.GA13672@caradoc.them.org>
2008-09-19 14:13   ` André Pönitz [this message]
2008-09-19 14:45     ` Daniel Jacobowitz
2008-09-19 15:21       ` André Pönitz
2008-09-19 15:26         ` Daniel Jacobowitz
2008-09-19 15:46           ` André Pönitz
2008-09-19 16:25             ` Daniel Jacobowitz

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=200809191612.23617.apoenitz@trolltech.com \
    --to=apoenitz@trolltech.com \
    --cc=gdb-patches@sources.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