[Github-comments] [geany/geany] "make check" unittests fail on Windows (#2677)

[Colomban Wendling]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20201130/acf095d2/attachment.htm>