#312 Runtime filename errors when ctags is built with LLVM.

open
nobody
None
5
2011-03-26
2011-03-26
Anonymous
No

I built ctags (from svn) on a mac with xcode 4 installed, which by defaults to using llvm (build 2335). When running the resulting ctags binary (-e), the first filename is always "(null)", and other filenames are erroneous too, some are empty, some are "^B" (control -B) and some are paths to the temp file ctags uses. I rebuilt ctags using gcc-4.2 and everything works as expected.

Discussion

  • Tim Blackman
    Tim Blackman
    2012-01-18

    It looks like using the standard compiler but disabling optimization is an effective work around:

    export CFLAGS=-O0

    Then configure and make as usual.

     
  • Michael Dwyer
    Michael Dwyer
    2012-08-03

    I'm on a Mac, and on OS X 10.7 and 10.8 this behavior occurs as well. If can be avoided by setting -O1 or -O0. -Os or -O2 result in the corrupted file names.

     
  • Bill Meier
    Bill Meier
    2012-09-30

    In my case: 'ctags -e ./*.c' generated a TAGS file with some of the filenames corrupted.

    I was using ctags 5.8-7 on an up-to-date Fedora 17.

    After downloading the ctags source, building and debugging ctags, I found that the problem was caused by the following strcpy()
    in the ctags file 'routines.c' function 'absolute_filename()':

    else if (slashp [2] == PATH_SEPARATOR || slashp [2] == '\0')
    {
    strcpy (slashp, slashp + 2);
    continue;
    }

    (This is code which removes ./ from a pathname string)

    As noted in the strcpy documentation: "...this function has undefined results if the strings overlap" which they clearly do in this case.

    Searching all the ctags top-level source files shows at least 2 other cases where strcpy is copying overlapping strings.

     
  • I see this behavior using ctags 5.8 from Homebrew. I think the cause is invalid use of 'const' for the global 'File'. I've uploaded a patch to https://gist.github.com/4010022. This resolves the issue for me.