public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* gdb_test_no_output
@ 2010-06-03 17:50 Michael Snyder
  2010-06-03 18:36 ` gdb_test_no_output Joel Brobecker
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Snyder @ 2010-06-03 17:50 UTC (permalink / raw)
  To: gdb, Joel Brobecker

Joel,

An oft-used feature of gdb_test is that, if the message string is
supplied but empty (""), no PASS/FAIL output is produced.  This is
used when you want to give a command to gdb without actually testing
anything.

Do you think you could make gdb_test_no_output behave the same?

Thanks,
Michael

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gdb_test_no_output
  2010-06-03 17:50 gdb_test_no_output Michael Snyder
@ 2010-06-03 18:36 ` Joel Brobecker
  2010-06-03 18:39   ` gdb_test_no_output Michael Snyder
  0 siblings, 1 reply; 3+ messages in thread
From: Joel Brobecker @ 2010-06-03 18:36 UTC (permalink / raw)
  To: Michael Snyder; +Cc: gdb

> An oft-used feature of gdb_test is that, if the message string is
> supplied but empty (""), no PASS/FAIL output is produced.  This is
> used when you want to give a command to gdb without actually testing
> anything.

It's very easy to implement the exact same behavior as gdb_test, but
are we certain that this is a valuable capability?  Looking at the
documentation for that function, one can find:

    # MESSAGE is an optional message to be printed.  If this is
    #   omitted, then the pass/fail messages use the command string as the
    #   message.  (If this is the empty string, then sometimes we don't
    #   call pass or fail at all; I don't understand this at all.)

The current implementation seems inconsistent; but also I don't think
that is really makes that much difference whether the test generates
a result or not.

But if that's what people want...

-- 
Joel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: gdb_test_no_output
  2010-06-03 18:36 ` gdb_test_no_output Joel Brobecker
@ 2010-06-03 18:39   ` Michael Snyder
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Snyder @ 2010-06-03 18:39 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb

Joel Brobecker wrote:
>> An oft-used feature of gdb_test is that, if the message string is
>> supplied but empty (""), no PASS/FAIL output is produced.  This is
>> used when you want to give a command to gdb without actually testing
>> anything.
> 
> It's very easy to implement the exact same behavior as gdb_test, but
> are we certain that this is a valuable capability?  Looking at the
> documentation for that function, one can find:
> 
>     # MESSAGE is an optional message to be printed.  If this is
>     #   omitted, then the pass/fail messages use the command string as the
>     #   message.  (If this is the empty string, then sometimes we don't
>     #   call pass or fail at all; I don't understand this at all.)
> 
> The current implementation seems inconsistent; but also I don't think
> that is really makes that much difference whether the test generates
> a result or not.
> 
> But if that's what people want...

It used to be a frequently used "idiom" -- if you wanted to do a
"next", for instance, just to set up for the next thing that you
needed to test, you would say

     gdb_test "next" "" ""

and it wouldn't add anything superfluous to the test output.

I'm currently looking at replacing the regexp part of those
usages with ".*", but the behavior in general is still useful,
I think.

Michael

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-06-03 18:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-03 17:50 gdb_test_no_output Michael Snyder
2010-06-03 18:36 ` gdb_test_no_output Joel Brobecker
2010-06-03 18:39   ` gdb_test_no_output Michael Snyder

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).