> There are six test samples which have CRLF line endings which still causes
> the tests to fail. Those could be converted to LF line endings:
>
> * 3184782.sql.tags
>
> * 3526726.tex.tags
>
> * bug1570779.sql.tags
>
> * ingres_procedures.sql.tags
>
> * matlab_backtracking.m.tags
>
> * matlab_test.m.tags
That' super duper weird, it's exactly the ones that would fail would CTags not
normalize line ends itself (which it does). If I manually remove that piece of
code, I get those failures on Linux:
```diff
diff --git a/ctags/main/read.c b/ctags/main/read.c
index e19f15697..3586a1aaa 100644
--- a/ctags/main/read.c
+++ b/ctags/main/read.c
@@ -857,7 +857,7 @@ static eolType readLine (vString *const vLine, MIO *const
mio)
* used forms of line breaks are: LF (UNIX/Mac OS X), CR-LF (MS-DOS)
and
* CR (Mac OS 9). As CR-only EOL isn't handled by gets() and Mac OS 9
* is dead, we only handle CR-LF EOLs and convert them into LF. */
- if (newLine && vStringLength (vLine) > 1 &&
+ if (false && newLine && vStringLength (vLine) > 1 &&
vStringChar (vLine, vStringLength (vLine) - 2) == '\r')
{
vStringChar (vLine, vStringLength (vLine) - 2) = '\n';
```
I really don't understand how Windows would make any difference here, I don't
see any code being conditional around there. And even if the libc was doing
the conversion CRLF→LF behind the scenes, that should not be a problem either
(unless maybe if there's a bug in the libc regarding fgetpos/fsetpos after such
mappings, but I wouldn't expect this kind of breakage).
@eht16 Could you check what exactly is the return value of the `mio_gets()`
calls in `readLine()` (or `iFileReadLine()` before *ctags_sync5*)? The only
explanation I have is that it doesn't return the format expected by this code
-- which would be surprising, but well.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2677#issuecomment-736096680
