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

[Anonymous]

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.

[Tim Blackman]

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]

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]

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.

[thefloweringash]

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.

[Ryan Carsten Schmidt]

This the patch MacPorts is using to fix the overlapping strcpy problem:

https://github.com/macports/macports-ports/blob/5f57b2016ff9b894b179dd3b29cc1eb6f714096f/devel/ctags/files/strcpy_overlap.patch