[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-hackers] [PATCH] Work around more Windows stupidity
From: |
Peter Bex |
Subject: |
[Chicken-hackers] [PATCH] Work around more Windows stupidity |
Date: |
Tue, 16 Feb 2016 21:32:42 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi all,
For some inexplicable reason, on Windows (and only without MSYS),
"make check" would fail on MingW (after applying the dbg-stub.c fix I
posted earlier, so that it builds, of course).
It would print something like this:
------------------------------------------------------------------------
Comparing files scrutiny.expected and SCRUTINY.OUT
***** scrutiny.expected
expression returns 2 values but is declared to have a single result
Note: in toplevel procedure `foo10':
***** SCRUTINY.OUT
expression returns 2 values but is declared to have a single result
Note: in toplevel procedure `foo10':
------------------------------------------------------------------------
Please note that we are calling "fc" with the /w switch, which would
make it equivalent to "diff -w" or "diff -w -b", like we do on UNIX.
I checked, double-checked and triple-checked (even manually poring over
a hex dump of the file) but couldn't find any differences, not even
whitespace differences except for the line ending differences.
Strangely enough, if I changed the line endings using dos2unix, fc
would stay silent. Converting it back with unix2dos would cause it
to output a difference again.
I didn't grok this *at all*, so I decided to search for documentation
on fc. Found this (it's for XP, but still relevant):
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fc.mspx
The following gives a better clue as to how this broken tool works than
the "/?" online help:
/lbn : Sets the n number of lines for the internal line buffer. The default
length of the line buffer is 100 lines. If the files that you are comparing
have more than this number of consecutive differing lines, fc cancels the
comparison.
So, it turns out that it maintains a fixed internal buffer containing
lines (but somehow each of those can be of arbitrary length? WTF!),
and with /w it doesn't discard lines which are identical after
compression of consecutive whitespace characters...
You really can't make this shit up. Thanks Microsoft, for two wasted
evenings!
Attached is a simple workaround for this new epic fail that can be added
to the long list of epic fails in Microsoft's repertoire. </rant>
Cheers,
Peter
0001-Fix-scrutiny-out-expected-comparison-in-tests-on-Min.chicken-5.patch
Description: Text Data
0001-Fix-scrutiny-out-expected-comparison-in-tests-on-Min.master.patch
Description: Text Data
signature.asc
Description: Digital signature
- [Chicken-hackers] [PATCH] Work around more Windows stupidity,
Peter Bex <=