[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile 2.0.9 build on mingw

From: Mark H Weaver
Subject: Re: guile 2.0.9 build on mingw
Date: Tue, 18 Jun 2013 18:28:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi Ludovic,

address@hidden (Ludovic Courtès) writes:

> Eli Zaretskii <address@hidden> skribis:
>> It's due to the CRLF thing.  These files are open in the "w" mode, but
>> then read using the "rb" mode.  So the CR character is left after the
>> newline is stripped, and botches the comparison.  The debug lines you
>> added show this (note the \r at the end):
>>      ;;; (line "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>>      FAIL: ports.test: file: binary mode ignores port encoding
>>      ;;; (line2 "\xe4\xb8\x80\xe4\xba\x8c\xe4\xb8\x89\r")
>>      FAIL: ports.test: file: binary mode ignores file coding declaration
> I think this patch solves the problem:
> diff --git a/libguile/rdelim.c b/libguile/rdelim.c
> index 9d14967..9f16c69 100644
> --- a/libguile/rdelim.c
> +++ b/libguile/rdelim.c
> @@ -154,6 +154,7 @@ SCM_DEFINE (scm_read_line, "%read-line", 0, 1, 0,
>           {
>           case EOF:
>           case '\n':
> +         case '\r':
>             delim = buf[index];
>             break;
> Probably the extra case should be #ifdef __MINGW32__, to make sure it
> has no effect on non-Windows users.  Thoughts?

I think this is a bad idea for multiple reasons:

* Handling of alternate line endings does not belong here; it belongs in
  a transcoder of some sort.

* This solution partially hides a problem (the user reading text without
  a proper transcoder), but does not solve the problem adequately.  It
  will behave badly on files with CRLF line endings.  There's no way to
  fix that in 'read-line' because its API does not allow for a
  multi-character delimiter.

* It potentially breaks existing code.  Making the change only on mingw
  would seem to mitigate that problem, but that just muddies the waters
  by introducing a difference in behavior that is not necessarily

* It hard codes the assumption that the line ending style of the file
  being read is determined by the platform you're running on.

To my mind, this is a bug in those tests.  So how about the following
patch instead?

What do you think?


diff --git a/test-suite/tests/ports.test b/test-suite/tests/ports.test
index 9b1c6c0..758f8f6 100644
--- a/test-suite/tests/ports.test
+++ b/test-suite/tests/ports.test
@@ -238,7 +238,7 @@
 (pass-if "file: binary mode ignores port encoding"
   (with-fluids ((%default-port-encoding "UTF-8"))
                (let* ((filename (test-file))
-                      (port (open-file filename "w"))
+                      (port (open-file filename "wb"))
                       (test-string "一二三")
                        (apply string
@@ -257,7 +257,7 @@
 (pass-if "file: binary mode ignores file coding declaration"
   (with-fluids ((%default-port-encoding "UTF-8"))
                (let* ((filename (test-file))
-                      (port (open-file filename "w"))
+                      (port (open-file filename "wb"))
                       (test-string "一二三")
                        (apply string

reply via email to

[Prev in Thread] Current Thread [Next in Thread]