Activity for cscope
-
regloh created ticket #305
cscope not able to change strings in cygwin
-
ben_tha_man posted a comment on ticket #304
I tried the updated version (sha1 hash: 208d7f6fe2839d65089fa7cc3c16112a37e0d120 ) and it fixes the issue I reported. Thank you. BTW, the mapping that I wrote in the description came out differently due to formatting. It should've been <C-\>g (ie. ctrl-backslash, g)
-
Hans-Bernhard Broeker modified ticket #304
Spurious bells when using mappings from cscope_maps.vim
-
Hmmm... that's very strange. That file has not been modified at all for 21 years. I find it extremely surprising that nobody would have ever noticed this in all that time. But then again, most people would have turned off the bell in their terminal emulators long ago, I think. :-) But for now I'll have to take your word for it. A modified version is now on the page.
-
Spurious bells when using mappings from cscope_maps.vim
-
marc jalfon posted a comment on ticket #200
I think a code base with a directory name that contains a space also yields the "File does not have expected format" issue. I hate spaces in filenames, but some colleagues like them...
-
Mike Dubrovsky modified a comment on ticket #214
can we do it as new command line argument ? or if the concern is "too many parameters" and not very common functionality ... let's do as environment variable ? I can post the diff if gatekeepers agree to accept the change.
-
can we do it as new command line argument ? or if concern is "too many parameters" and not very common functionality ... let's do as environment variable ? I can post the diff if gatekeepers agree to accept the change.
-
can we do it as new command line argument ? or if concern is "too much parameters" ... let's do as environment variable ? I can post the diff if gatekeepers agree to accept the change.
-
can we do it as new command line argument ? or if concern is "too much parameters" ... let's do as environment variable ? I can put a diff if gatekeepers agrees to accept the change.
-
Setting aside technical issues with the change itself, like having modifications unrelated to the issue at hand, I'm missing an explanation what this change is supposed to be needed for. I.e. on what basis would one conclude that any backslash contained in an argument to compath() was not meant to be part of the actual filename? Where would filenames come from that have such extraneous backslashes? And if there are any of those, how would anyone know whether, e.g., a "\t" is supposed to stand for...
-
György Kövesdi created merge request #6 on Git
File path can contain backslash-escaped characters
-
The bufsize change cannot reasonably be the cause here. BUFSIZ is 1024 on some other platforms, too, where cscope has worked just fine for decades.
-
b'Hans-Bernhard Broeker committed [978e2c]
Merge /u/dominikoeo/cscope/ branch bugfix/access-beyond-end-of-string-when-search-called-by-fails into master
-
fix: access beyond end of string when search called by fails
-
docs: typo fixes in man page and in source code comments
-
Dominique Pelle created merge request #5
fix: vim cscope test was failing on macOS Monterey (with M1 processor)
-
docs: typo fixes in man page and in source code comments
-
fix: access beyond end of string when search called by fails
-
make cscope not fail if there are no source files in the directory cscope is being ran
-
Ryan Carsten Schmidt posted a comment on ticket #303
I've reported it to Apple as feedback id FB9866173.
-
dyld[39272]: symbol not found in flat namespace '_yylex'
-
If strip can turning a working binary into a broken one then yes, that does mean it's quite thoroughly broken.
-
I found that in the MacPorts portfile, we were running strip cscope after compilation, and that removing that fixed the problem. I don't know why we were stripping the executable, but we had been doing so ever since cscope was added to MacPorts back in 2003. macOS was a much younger operating system back then and perhaps there was a good reason for stripping things at that time or perhaps it was just a whim of whoever added it. I don't know why stipping the executable is now all of a sudden causing...
-
The fact that building the same source for different versions of the same platform apparently gives a different result is a very strong indication that whatever the actual reason for this is, it has very little or nothing to do with the cscope source code. Given that, and the additional limitation that I don't have any personal experience,with, nor access to MacOS machines, I'm afraid you're on your own. I can only offer some rough suggestions: yylex() is part of the scanner generated by whatever...
-
The fact that building the same source for different versions of the same platform apparently gives a different result is a very strong indication that whatever the actual reason for this is, it has very little or nothing to do with the cscope source code. Given that, and the additional limitation that I don't have any personal experience, with nor access, to MacOS machines, I'm afraid you're on your own. I can only offer some rough suggestions: yylex() is part of the scanner generated by whatever...
-
dyld[39272]: symbol not found in flat namespace '_yylex'
-
I don't agree with the reasoning behind this change. The user should most definitely not expect that cscope would just use the existing file as-is, instead of trying to update the database. If they wanted that behaviour, they should have used the -d option. And no, turning on -R is by no means the only or obviously correct answer either. For all we know the user may just not have been aware they ran the program in completely the wrong folder.
-
I don't agree with the reasoning behind this change. The user should most definitely expect that cscope would just use the existing file as-is, instead of trying to update the database. If they wanted that behaviour, they should have used the -d option. And no, turning on -R is by no means the only or obviously correct answer either. For all we know the user may just not have been aware they ran the program in completely the wrong folder.
-
Arjun created merge request #2
make cscope not fail if there are no source files in the directory cscope is being ran
-
Steve Hayes posted a comment on ticket #200
I think a code base with duplicated function prototypes can yield the "File does not have expected format" issue. A very minimal example does not reproduce this issue for me. My solution was delete the duplicated function prototypes from my codebase and enjoy cscope!
-
blarsen created ticket #302
cscope_maps.vim issues when reopening a file in a project
-
This actually is a problem in the scanner, first. The Y(a) macro call is mistaken for a function definition, with the braces in the #define X(a) line as its function body, and everything between as the (K&R-style) argument definition list. Then as the parser goes on it finds #define X(a) as a macro definition. And then inside that, it mistakes "}while(0)" as a function call. The query/output routine later barfs as it tries to find the beginning of the line that function call was in, because the database...
-
This actually is a problem in the scanner, first. The Y(a) macro call is mistaken for a function definition, with the braces in the #define X(a) line as its function body, and everything between as the (K&R-style) argument definition list. Then as the parser goes on it finds #define X(a) as a macro definition. And then inside that, it mistakes "}while(0)" as a function call. The query/output routine later barfs as it tries to find the beginning of the line that function call was in, because the database...
-
<REDACTED> posted a comment on ticket #301
Here is the example file that I used.
-
<REDACTED> created ticket #301
Internal error: cannot get source line from database
-
15.9 + master: build fails with gcc 10.2.1
-
It might be interesting to tell the public what that mistake was, so others can avoid tripping over it. I will close this anyway.
-
Tomasz Kłoczko posted a comment on ticket #299
Feel free to close that ticket. I found what I've done wrong :P
-
Chinmay Chhajed created ticket #300
Doesn't find inline functions
-
Well, somehow it managed to hide the correct header file, curses.h, from the configure script. Instead it found the C++ version: cursesw.h. How exactly that happened can only be analyzed by looking at your config.log file. FWIW the original script would never even look for a file of that name.
-
I'm using ncurses 6.2-4.2020081. None of other my packages complains about anything wrong in ncurses header files.
-
Inconsistent enum tagging
-
This is actually a duplicate of bug #220
-
c++ namespace key word not supported
-
Full path no longer printed using -P
-
cscope cannot find function which is parse as function pointer
-
15.9 + master: build fails with gcc 10.2.1
-
AFAICS none of those failures actually originate in cscope itself. Note how they're all in system library header files, which somehow expanded C++-only pieces to a C compiler. I would suspect the root cause to be either in a broken ncurses installation, or a broken RPM build script.
-
15.9 + master: build fails with gcc 10.2.1
-
Yichao Yu modified a comment on ticket #214
but this misunderstands the nature of lstat(). lstat() follows the link so the stat struct returned is that of the referenced file. While there might be other reason this is rejected, this statement is wrong. From the manpage of fstatat on linux. The lstat() function shall be equivalent to stat(), except when path refers to a symbolic link. In that case lstat() shall return information about the link, while stat() shall return information about the file the link references. and the original poster...
-
but this misunderstands the nature of lstat(). lstat() follows the link so the stat struct returned is that of the referenced file. While there might be other reason this is rejected, this statement is wrong. From the manpage of fstatat on linux. The `lstat()` function shall be equivalent to `stat()`, except when path refers to a symbolic link. In that case `lstat()` shall return information about the link, while `stat()` shall return information about the file the link references. and the original...
-
Hans-Bernhard Broeker committed [eaea31]
emacs plugin fixup: GNU/Emacs 27.1 removes function process-kill-without-query
-
Ticket moved from /p/gnuplot/bugs/2221/ Can't be converted: _milestone: _priority:
-
extern "C" states that the variable or function has C linkage. Yes. But only in the C++ language. In C that would a syntax error.
-
Alex P posted a comment on ticket #295
extern is a C keyword. It serves two puposes - states that the variable is declared externally(outside of this file) and can specify the linkage type. extern "C" states that the variable or function has C linkage. It tell compiler that this function name should not be mangled. I thought there were other linkage types than just "C" but I couln't find any examples. What would be the proper fix in cscope for this? Take out all things between #ifdef __cplusplus/#endif?
-
extern "C" statement is a valid C statement. No, it's really not. That's why it's almost invariably enclosed in an #ifdef __cplusplus #endif bracket: so the C compiler never sees it.
-
Is there another fix possible for this issue? This is a valid issue since extern "C" statement is a valid C statement.
-
There are at least 3 problems with that patch: 1. it triggers on every occurance of "C" 2. it blindly assumes that extern "C" will only ever appear with a { after it 3. it blindly assumes that extern "C" { can only appear at the outermost bracelevel
-
extern "C" used in include file prevents enumeration members from appearing in global scope
-
Hans-Bernhard Broeker committed [3f9e3d]
doc/cscope.1: Fix hyphens
-
Hans-Bernhard Broeker committed [bb7f25]
contrib/ocs: Fix bashims (Closes: #480591)
-
Hans-Bernhard Broeker committed [e1b4cb]
fscanner: swallow function as parameters
-
non getopt option parsing broken
-
cscope: cannot find file
-
Line number offset while browsing perl code
-
segmentation fault while building library
-
Building Under Cygwin
-
-I options doesn't handle symbolic link
-
parser breaks on NUL before preprocessor command line
-
cscope ignores symlinks to files
-
Display
-
DOS-style files really do not belong among cscope's input.
-
Build error under cygwin
-
Ticket moved from /p/cscope/bugs/298/
-
Michael Schuster created ticket #298
feedback on support-request #17 is wrong
-
Belated notice: cscope 15.9 released
-
Belated notice: cscope 15.9 released
-
Josh Allmann posted a comment on ticket #297
what you really need is a fresher vim. Compiled a vim from git master, and it seems to work now with cscope master. Thanks for the tip.
-
15.9 - searching for an undefined symbol causes cscope/vim to freeze
-
Reverting that change would be quite obviously the wrong idea. Without that fix, cscope might just crash on the spot, which cannot possibly be correct. That indicates the actual problem is closer to vim than to cscope, here. I suspect (your version of) the cscope support in vim just don't expect the output "Unable to search database" from its "cscope -l" subprocess. And indeed, on inspection of the vim sources, they did add code to handle this new response in January of 2018. So: what you really...
-
Can confirm that this happens here on macOS with the following steps: Clone cscope git master at https://git.code.sf.net/p/cscope/cscope export EDITOR=vim Run cscope -R to generate an index. Here, I used the root of the ffmpeg git repo. Open ffmpeg.c file via "Find this file:" Run ":cs f s <undefined-symbol>" within vim.</undefined-symbol> Vim freezes / becomes unresponsive and has to be killed. Was able to bisect and narrow it down to this commit: 6d646e7528f499d6df559cffc43ee11dd424c501 $ git show...
-
This does not reproduce here. Neither in Vim, nor in cscope when used on its own. This makes it likely that the homebrew port you're using is the problem.
-
Adam Incera created ticket #297
15.9 - searching for an undefined symbol causes cscope/vim to freeze
-
Heath Caldwell modified a comment on merge request #1
According to K&R, "fflush causes any buffered but unwritten data to be written". According to the Linux man page, "fflush() forces a write of all user-space buffered data ...". From my understanding, I think that it is safe to regard a successful fflush() call as guaranteeing that the data will be available for a future read from the underlying file. For more safety, the return value should probably be checked (but the same should be followed if depending on fclose() to guarantee that the data was...
-
According to K&R, "fflush causes any buffered by unwritten data to be written". According to the Linux man page, "fflush() forces a write of all user-space buffered data ...". From my understanding, I think that it is safe to regard a successful fflush() call as guaranteeing that the data will be available for a future read from the underlying file. For more safety, the return value should probably be checked (but the same should be followed if depending on fclose() to guarantee that the data was...
-
Fix double fclose() on script file in changestring()
-
I'm less than fully convinced that fflush() is sufficient here. That's basically just a friendly hint that the stdio.h functions should do something about getting stuff out there, but it doesn't fully guarantee the data are available to the executed shell immediately after. I've implemented a different solution that keeps the outside effects as it was, while still avoiding the double fclose().
-
Hans-Bernhard Broeker committed [f632c3]
Avoid double-free via double fclose in changestring.
-
Fix double fclose() on script file in changestring()
-
Hans-Bernhard Broeker committed [f69347]
Avoid putting directories found during header search into srcfiles.
-
mikhail nefedov posted a comment on ticket #90
Got it!
-
No, that wouldn't be truly sensible. addsrcfile() has a well-defined job, as given by its name: add something to srcfiles. Doing more in there would be somewhat wastefule, e.g. in the cases where it's called on reading the current database, i.e. with pathnames that have already been vetted the previous time round.
-
Thanks. Understood about not opening the dir.h BTW would it be sensible to move the checking for regular files into the addsrcfile()?
-
"Cannot open file" error on erroneously added directory for incfile.
-
Patch looks good. But just in case, please note that even with the patch, cscope would not find that header dir.h while looking for <dir>
-
"Cannot open file" error on erroneously added directory for incfile.
-
Hans-Bernhard Broeker committed [6a6998]
Cull extraneous declaration
-
Hans-Bernhard Broeker committed [39fb38]
[modified from patch #81] Fix reading include files in -c mode
-
Hans-Bernhard Broeker committed [aafa9a]
The file has not been called config-h.in for ages.