Re: Is ``break main if(1)'' legal?

Re: Is ``break main if(1)'' legal?

[Fernando Nasser]

Andrew Cagney wrote:
> 
> (vs ``break main if (1)'')
> Some parts of the code (decode_line_1()) think it is legal but other
> parts (break_command_1()) don't.
> 

(1) is a perfectly valid logical expression of "true".  It makes no
sense setting a conditional breakpoint to always true, but rejecting the
expression as not valid is wrong.

What is break_command_1() complaining about?

-- 
Fernando Nasser
Cygnus Solutions - Toronto Office       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From guo@cup.hp.com Wed Dec 15 10:17:00 1999
From: Jimmy Guo <guo@cup.hp.com>
To: Jeffrey A Law <law@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg15: hppah-nat.c & related 
Date: Wed, 15 Dec 1999 10:17:00 -0000
Message-id: <Pine.LNX.4.10.9912150951120.29808-100000@hpcll168.cup.hp.com>
References: <881.945247412@upchuck>
X-SW-Source: 1999-q4/msg00387.html
Content-length: 1439

Jeff, thanks for taking the time looking at the patches!

Since I'm splitting apart changes made by HP, in various areas, over 12
months, into multiple patches, there's a need for me to run indent on
the patched source to ensure that the GNU coding style in gdb source is
adhered to.  I will make sure that pure formatting changes (line breaks)
made by HP are not introduced along with real changes.

However as we've discovered, due to a combination of a potential indent
program problem and the fact that there're places in snapshot sources
where formatting is actually necessary, there's another kind of pure
formatting changes which can come from this combination (and my running
indent before making the patch).  There're several ways to handle this:

1) generate patch using GNU diff -w option (ignore white space), and
   apply patch using patch -l (--ignore-whitespace) option.
   :: I like this approach and I'll do it if you guys are willing to
   give this a try.

2) don't run indent before generating patch, have maintainers do
   that before checking into CVS.
   :: could work.  If necessary I can provide a ksh script to do this,
   incorporating the special-case handlings documented by Stan during
   the GDB reformat (so one do not indent a file which is not supposed
   to be indented).

3) patch submitter manually remove pure formatting change noises from
   patch.
   :: least favored.

- Jimmy Guo, guo@cup.hp.com

Re: Is ``break main if(1)'' legal?

[Elena Zannoni]

Fernando Nasser writes:
 > Andrew Cagney wrote:
 > > 
 > > (vs ``break main if (1)'')
 > > Some parts of the code (decode_line_1()) think it is legal but other
 > > parts (break_command_1()) don't.
 > > 
 > 
 > (1) is a perfectly valid logical expression of "true".  It makes no
 > sense setting a conditional breakpoint to always true, but rejecting the
 > expression as not valid is wrong.
 > 
 > What is break_command_1() complaining about?
 > 

I think Andrew is referring to the space between 'if' and the condition?
Elena

 > -- 
 > Fernando Nasser
 > Cygnus Solutions - Toronto Office       E-Mail:  fnasser@cygnus.com
 > 2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
 > Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From law@cygnus.com Wed Dec 15 10:41:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com, binutils@sourceware.cygnus.com
Subject: Re: (patch) hpjyg07: include/hp-symtab.h 
Date: Wed, 15 Dec 1999 10:41:00 -0000
Message-id: <2374.945282280@upchuck>
References: <Pine.LNX.4.10.9912150840410.29519-100000@hpcll168.cup.hp.com>
X-SW-Source: 1999-q4/msg00391.html
Content-length: 1124

  In message < Pine.LNX.4.10.9912150840410.29519-100000@hpcll168.cup.hp.com >you 
write:
  > >  > 1999-11-03      Jimmy Guo       <guo@cup.hp.com>
  > >  > 
  > >  >         * hp-symtab.h (HP_LANGUAGE_FORTRAN): Declare, replaces
  > >  >         HP_LANGUAGE_F77.
  > >I don't see the point behind making this change.  Also note that it will
  > >break gdb unless you change hp-psymtab-read.c at the same time.
  > 
  > >Why are you making this change?
  > 
  > We've added Fortran 90 support and this change is to cover Fortran90 as
  > well.
Ah yes.  That makes perfect sense.

  > But it could be that hp-psymtab-read.c needs change at the same
  > time ... I thought I tested each patch but one can never be sure.
grep HP_LANGUAGE_F77 will show one use in hp-psymtab-read.c  so it
should be updated to the newer name.  I'll take care of that.

It probably does not matter for this specific patch, but in general if we can
keep compatibility we should.  I went ahead and updated the patch so that it
provides by HP_LANGUAGE_FORTRAN and HP_LANGUAGE_F77.

The changes should appear in the next gdb snapshot.

Thanks,
jeff