Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Joel Brobecker'" <brobecker@adacore.com>,
	       "'Michael Snyder'" <msnyder@vmware.com>
Cc: <gdb-patches@sourceware.org>
Subject: RE: [RFA] p-typeprint.c, move pointer use to after null-check.
Date: Tue, 08 Mar 2011 14:56:00 -0000	[thread overview]
Message-ID: <004e01cbdd9d$5d383600$17a8a200$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <20110308051024.GL30306@adacore.com>



> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : mardi 8 mars 2011 06:10
> À : Michael Snyder
> Cc : gdb-patches@sourceware.org; Pierre Muller
> Objet : Re: [RFA] p-typeprint.c, move pointer use to after null-check.
> 
> > If it's worth checking for null...
> >
> > OK?
> >
> 
> > 2011-03-01  Michael Snyder  <msnyder@vmware.com>
> >
> > 	* p-typeprint.c (pascal_type_print_method_args): Don't use
> > 	pointer until after null-check.
> I think I get the drift of the code, and ISTM that the check for NULL
> might be misleading. I think that "physname" can never be null, by
> virtue of how it's called. What I would do is just remove the check
> against NULL (we can add a gdb_assert at the same time, which would
> force us to declare the is_constructor/is_destructor variables without
> initial value - no big deal).
> 
> Pierre?

  No, I think that the code relies on the fact that physname
is never null, but that the constructor or destructor could have no
parameters, in which case  physname would point to \0
after the '+= 6'.
  Parameterless pascal procedure/functions
do not require opening/closing braces like C does.
  So I still think that the current code is correct.
 So to answer to Michael, with my apologies for the delay,
I do think that your patch is not correct and should
not be applied as is.
 
> A few remarks:
> 
> The function could (should?) be made static, unless I grep'ed wrong
  Should indeed...
  
 
> > +      if (is_constructor || is_destructor)
> > +	{
> > +	  physname += 6;
> > +	}
> 
> Useless extra curly braces...
 OK, while correcting these, I also saw that:  

Is this correct:
   if (physname && (*physname != 0))
or is:
   if (physname && *physname != 0)

better?
or should I use:
   if (physname && *physname != '\0')


Pierre Muller
GDB pascal language maintainer




  reply	other threads:[~2011-03-08 14:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01 20:37 Michael Snyder
2011-03-07 20:19 ` Michael Snyder
2011-03-08  6:54 ` Joel Brobecker
2011-03-08 14:56   ` Pierre Muller [this message]
2011-03-08 15:30     ` Joel Brobecker

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='004e01cbdd9d$5d383600$17a8a200$@muller@ics-cnrs.unistra.fr' \
    --to=pierre.muller@ics-cnrs.unistra.fr \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=msnyder@vmware.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