Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ctest -V has two failing tests out of twelve on Cygwin #6667

Open
dvklopfenstein opened this issue Dec 10, 2023 · 2 comments
Open

ctest -V has two failing tests out of twelve on Cygwin #6667

dvklopfenstein opened this issue Dec 10, 2023 · 2 comments

Comments

@dvklopfenstein
Copy link

dvklopfenstein commented Dec 10, 2023

ctest -V has two failing tests out of twelve on Cygwin

Thank you so much for creating libgit2. It looks like a fantastic project and I am looking forward to using it in my own code.

Reproduction steps

$ git clone https://github.com/libgit2/libgit2.git
$ cd libgit2/
$ mkdir build
$ cd build/
$ cmake ..
$ cmake --build .
$ ctest -V

Expected behavior

100% tests passed

Actual behavior

83% tests passed, 2 tests failed out of 12

Total Test time (real) = 616.56 sec

The following tests FAILED:
       	  1 - offline (Failed)
       	 12 - util (Failed)
Errors while running CTest
Output from these tests are in: /home/dvklo/clone/libgit2/libgit2/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.

Version of libgit2 (release number or SHA1)

Code from git clone https://github.com/libgit2/libgit2.git executed on 2023_1209

Operating system(s) tested

$ uname
CYGWIN_NT-10.0-22621

Log file from ctest -V: libgit2.log

LastTest.log

@ethomson
Copy link
Member

I'm not a Cygwin user, but I'm hopeful that it's something simple where WIN32 is accidentally or intentionally unset on windows based Cygwin platforms, and we need to fix our compile time platform detection.

@boretrk
Copy link
Contributor

boretrk commented Dec 11, 2023

Some of the errors are the same as #6655 but there seems to be some differences.
One problem could be that we pass signed characters into the character classification macros.

From newlib:ctype.h:

/* These macros are intentionally written in a manner that will trigger
   a gcc -Wall warning if the user mistakenly passes a 'char' instead
   of an int containing an 'unsigned char'.  Note that the sizeof will
   always be 1, which is what we want for mapping EOF to __CTYPE_PTR[0];
   the use of a raw index inside the sizeof triggers the gcc warning if
   __c was of type char, and sizeof masks side effects of the extra __c.
   Meanwhile, the real index to __CTYPE_PTR+1 must be cast to int,
   since isalpha(0x100000001LL) must equal isalpha(1), rather than being
   an out-of-bounds reference on a 64-bit machine.  */
#define __ctype_lookup(__c) ((__CTYPE_PTR+sizeof(""[__c]))[(int)(__c)])

So gcc should warn about it, but other compilers might not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants