[Cscope-devel] [ cscope-Bugs-528357 ] -q can't handle '#include <foo/bar.h>'

[<no...@so...>]

Bugs item #528357, was opened at 2002-03-10 21:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=528357&group_id=4664

Category: None
Group: None
>Status: Closed
Resolution: Postponed
Priority: 3
Submitted By: Jason Duell (jcduell)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: -q can't handle '#include <foo/bar.h>'

Initial Comment:
If you search for 'find all files that include bar.h',
it will work if you don't pass the -q flag to cscope,
but it's broken for includes that include path
information (ex: "#include <sys/types.h>" if -q is
passed (nothing is found).

I've attached a very simple directory structure that
shows the problem.  Go into the top level directory,
and try searching for 'foo.h' via

   cscope -R

then

   cscope -Rq

and you'll see.

This bug only happens for nested includes:

   #include "nest/bar.h"

is broken under -q, but 

   #include "regular.h"

is still found.

----------------------------------------------------------------------

>Comment By: Jason Duell (jcduell)
Date: 2002-03-13 10:38

Message:
Logged In: YES 
user_id=125727

OK, so we've decided to make both the -q and non-q modes
work so that they will return any includes of <sys/time.h>,
<bits/time.h>, etc., along with includes of <time.h>.  If
the user wants just <time.h>, they can search for '^time.h$'.

Bug closed. 

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-03-12 11:39

Message:
Logged In: YES 
user_id=27517

Let's move the debate to cscope-devel then, and put the bug
report on the back burner for the time being.

Re your P.S.: right, that isn't mentioned anywhere in the
man page.
But the online help (? in interactive cscope) mentions it:

--- quote ---
Press the RETURN key repeatedly to move to the desired input
field, type the
pattern to search for, and then press the RETURN key.  For
the first 4 and
last 2 input fields, the pattern can be a regcmp(3X) regular
expression.
--- ends ---

----------------------------------------------------------------------

Comment By: Jason Duell (jcduell)
Date: 2002-03-12 11:33

Message:
Logged In: YES 
user_id=125727

I agree that is debatably not a bug at all, but just a minor
difference between how the modes work.  It's slightly
regrettable that they work differently, but I'm not sure
that it's worth fixing.  Should we just close/delete this
bug report, or should we lower it's importance level (I've
already lowered it some)?

P.S.  Until your note, I never even knew that you could use
regular expressions in the non-grep searches!  This doesn't
appear to be documented anywhere in the man page...

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2002-03-12 08:15

Message:
Logged In: YES 
user_id=27517

To some extent, that figures.  Note that no file actually
does #include "foo.h", so there's no strict reason that the
search for "Files including this file" should find one.

That it gets found if -q is not used is due to the fact that
in non-q mode, the search for includes effectively has an
implicit '.*' regexp added at the front, because in
findinit:

603             /* allow a partial match for a file name */
604             if (field == FILENAME || field == INCLUDES)
{

The equivalent code for searches using the invlib.[ch]
routines doesn't do this.

The question remains whether finding partial matches,
*unconditionally*, is really a good plan here.  If you
really want a
partical match, you could always search for

	.*foo\.h

instead.

----------------------------------------------------------------------

Comment By: Jason Duell (jcduell)
Date: 2002-03-12 06:47

Message:
Logged In: YES 
user_id=125727

I've just determined that when -qR is passed, #include
searches for 'nest/foo.h' still work, but searches for plain
old 'foo.h' do not.  When only -R is used, both types of
searches work.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=528357&group_id=4664