Attached patch fixes PR libfortran/23262 (and 23264): we need to switch
I/ to binary-mode (instead of text-mode) on mingw32. With text-mode,
the I/ library makes magical things with newlines, but it makes it
impossible to use lseek and ftruncate. So, we need not to use them, and
take care ourselves of outputting the right newline characters.
The patch adds a configure test (compile-test, with target-based guess
for cross-compilers) to know whether target is a system with CRLF line
terminator (and has BINARY open() flag available). This case, AFAIK,
does arise only for mingw32.
This does not change things on platforms other than mingw32, but it
definetely improve I/ on mingw32.
K for 4.0 and mainline?
FX
Index: libgfortran/acinclude.m4
RCS file: /,v
retrieving revision 1.6
diff -p -u -r1.6 acinclude.m4
libgfortran/acinclude.m427 Aug 2005 16:01:51 -00001.6
libgfortran/acinclude.m43 Sep 2005 17:07:26 -0000
@@ -183,3 +183,50 @@ esac])])
if test x"$have_unlink_open_file" = xyes; then
AC_DEFINE(HAVE_UNLINKPEN_FILE, 1, [Define if target can unlink open files.])
fi])
+
+dnl Check whether CRLF is the line terminator
+AC_DEFUN([LIBGFR_CHECK_CRLF], [
+ AC_CACHE_CHECK([whether the target has CRLF as line terminator],
+ have_crlf, [
+ AC_TRY_RUN([
+/* This test program should exit with status 0 if system uses a CRLF as
+ line terminator, and status 1 otherwise.
+ Since it is used to check for mingw systems, and should return 0 in any
+ other case, in case of a failure we will not use CRLF. */
+#include <sys/stat.h>
+#include <stdlib.h>
+#include <fcntl.h>
+#include <stdio.h>
+
+int main ()
+{
+#ifndef BINARY
+ exit(1);
+#else
+ int fd, bytes;
+ char buff[5];
+
+ fd = open ("foo", WRNLY | CREAT | TRUNC, S_IRWXU);
+ if (fd < 0)
+ exit(1);
+ if (write (fd, "\n", 1) < 0)
+ perror ("write");
+
+ close (fd);
+
+ if ((fd = open ("foo", RDNLY | BINARY, S_IRWXU)) < 0)
+ exit(1);
+ bytes = read (fd, buff, 5);
+ if (bytes == 2 && buff[0] == '\r' && buff[1] == '\n')
+ exit(0);
+ else
+ exit(1);
+#endif
+}], have_crlf=yes, have_crlf=no, [
+case "${target}" in
+ *mingw*) have_crlf=yes ;;
+ *) have_crlf=no;;
+esac])])
+if test x"$have_crlf" = xyes; then
+ AC_DEFINE(HAVE_CRLF, 1, [Define if CRLF is line terminator.])
+fi])
Index: libgfortran/configure.ac
RCS file: /,v
retrieving revision 1.32
diff -p -u -r1.32 configure.ac
libgfortran/configure.ac2 Sep 2005 20:24:49 -00001.32
libgfortran/configure.ac3 Sep 2005 17:07:27 -0000
@@ -261,6 +261,12 @@ LIBGFR_CHECK_ATTRIBUTE_ALIAS
# Various other checks on target
LIBGFR_CHECK_UNLINKPEN_FILE
+# Check whether line terminator is LF or CRLF
+LIBGFR_CHECK_CRLF
+
AC_CACHE_SAVE
if test ${multilib} = yes; then
Index: libgfortran/io/transfer.c
RCS file: /,v
retrieving revision 1.54
diff -p -u -r1.54 transfer.c
libgfortran/io/transfer.c17 Aug 2005 02:48:57 -00001.54
libgfortran/io/transfer.c3 Sep 2005 17:07:27 -0000
@@ -1412,13 +1412,24 @@ next_record_w (void)
break;
case FRMATTED_SEQUENTIAL:
+#ifdef HAVE_CRLF
+ length = 2;
+#else
length = 1;
+#endif
p = salloc_w (current_unit->s, &length);
if (!is_internal_unit())
{
if (p)
- *p = '\n'; /* No CR for internal writes. */
+ { /* No new line for internal writes. */
+#ifdef HAVE_CRLF
+ p[0] = '\r';
+ p[1] = '\n';
+#else
+ *p = '\n';
+#endif
+ }
else
goto io_error;
}
Index: libgfortran/io/unix.c
RCS file: /,v
retrieving revision 1.36
diff -p -u -r1.36 unix.c
libgfortran/io/unix.c2 Sep 2005 20:24:49 -00001.36
libgfortran/io/unix.c3 Sep 2005 17:07:27 -0000
@@ -1000,7 +1000,12 @@ tempfile (void)
if (mktemp (template))
do
+#ifdef HAVE_CRLF
+ fd = open (template, RDWR | CREAT | EXCL | BINARY,
+ S_IREAD | S_IWRITE);
+#else
fd = open (template, RDWR | CREAT | EXCL, S_IREAD | S_IWRITE);
+#endif
while (!(fd == -1 && errno == EEXIST) && mktemp (template));
else
fd = -1;
@@ -1084,6 +1089,10 @@ regular_file (unit_flags *flags)
}
/* rwflag |= LARGEFILE; */
+
+#ifdef HAVE_CRLF
+ crflag |= BINARY;
+#endif
mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IRTH | S_IWTH;
fd = open (path, rwflag | crflag, mode);
2005-09-03 Francois-Xavier Coudert <coudert (AT) clipper (DOT) ens.fr>
* acinclude.m4 (LIBGFR_CHECK_CRLF): New check.
* configure.ac: Use new check.
* configure.in: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* io/transfer.c (next_record_w): Add case for CRLF as line
terminator.
* io/unix.c (tempfile, regular_file): files with
BINARY on systems with CRLF.

FX Coudert wrote:
Attached patch fixes PR libfortran/23262 (and 23264): we need to switch
I/ to binary-mode (instead of text-mode) on mingw32. With text-mode,
the I/ library makes magical things with newlines, but it makes it
impossible to use lseek and ftruncate. So, we need not to use them, and
take care ourselves of outputting the right newline characters.

The patch adds a configure test (compile-test, with target-based guess
for cross-compilers) to know whether target is a system with CRLF line
terminator (and has BINARY open() flag available). This case, AFAIK,
does arise only for mingw32.

This patch is likely to do interesting things on Cygwin, which has an
option (at install time) to switch between DS and Unix newlines.

According to my cursory understanding of how this works [1], if DS mode
is selected at install (or, more particularly, when the disk is mounted;
it's a mount option), Cygwin uses the text-mode or binary-mode switch to
decide whether or not to translate the line endings from DS-mode (on
disk) to Unix-mode (as seen by the program).

My guess is that the result of this patch will be to "freeze" the
newline handling on Cygwin to the setting that was active at compile
time, rather than allowing it to adapt to the current system settings.
For distributed binaries, this means the end user's settings would get
completely ignored.

Unfortunately, I don't understand enough about this to say anything with
specificity, or have any suggestions for fixing it
- Brooks

[1] Based on this FAQ answer:
#faq.api.cr-lf

This patch is likely to do interesting things on Cygwin, which has an
option (at install time) to switch between DS and Unix newlines.

According to my cursory understanding of how this works [1], if DS mode
is selected at install (or, more particularly, when the disk is mounted;
it's a mount option), Cygwin uses the text-mode or binary-mode switch to
decide whether or not to translate the line endings from DS-mode (on
disk) to Unix-mode (as seen by the program).

My guess is that the result of this patch will be to "freeze" the
newline handling on Cygwin to the setting that was active at compile
time, rather than allowing it to adapt to the current system settings.
For distributed binaries, this means the end user's settings would get
completely ignored.

I'm not sure how this works either, but from the FAQ link you posted, it
seems clear that only a few people use the mount switch. Plus, I do
think that specifying binary mode in the code does override the user
option (the opposite behaviour doesn't seem to make sense to me).

Moreover, the current situation is that the compiler souldn't work on
cygwin with text-mode switch, for the same reasons it doesn't work on
mingw32.

Can someone accointed with cygwin experiment a bit with this patch and
give us an update on the current situation? Maybe Paul T when his NIST
patch is done?

FX

FX Coudert wrote:
>>This patch is likely to do interesting things on Cygwin, which has an
>>option (at install time) to switch between DS and Unix newlines.
>>
>>According to my cursory understanding of how this works [1], if DS mode
>>is selected at install (or, more particularly, when the disk is mounted;
>>it's a mount option), Cygwin uses the text-mode or binary-mode switch to
>>decide whether or not to translate the line endings from DS-mode (on
>>disk) to Unix-mode (as seen by the program).
>>
>>My guess is that the result of this patch will be to "freeze" the
>>newline handling on Cygwin to the setting that was active at compile
>>time, rather than allowing it to adapt to the current system settings.
>>For distributed binaries, this means the end user's settings would get
>>completely ignored.

I'm not sure how this works either, but from the FAQ link you posted, it
seems clear that only a few people use the mount switch. Plus, I do
think that specifying binary mode in the code does override the user
option (the opposite behaviour doesn't seem to make sense to me).

What wasn't clear from that FAQ link is that, while few people use the
mount switch directly, there's a checkbox in the Cygwin install program
to choose DS or Unix line endings -- and, unless I'm mistaken, that
checkbox sets up a default for how "mount" is called for the disks when
the computer first boots. So the switch is effectively being used by
everyone who chooses the "DS" option at install time.

Specifying binary mode appears to override the user option, yes. What
I'm thinking is that, when a gfortran-compiled program is creating a
text file, it may not be appropriate to override the user option --
because, if we do, a Cygwin user may not get the line ending type that
they want.

The reason that I say this will be "interesting" [1] is that I'm pretty
sure your compile-time switch will return different results depending on
the way Cygwin is set on the compiling computer. And thus Paul T.'s
setting on his computer -- rather than anything in the gfortran code or
in the Cygwin code -- will determine the line endings for everyone who
uses his compiled binaries. (In practice, this is probably not a
serious problem, but it's going to be a pain to track down if it becomes
one, unless there's a comment about it somewhere obvious.)

I may have a chance to poke at this a bit and confirm some of this
experimentally in the next couple of weeks; if I do, I'll report back.
- Brooks

[1] In the sense of the "may you live in interesting times" curse

FXavier Coudert wrote:

>>it may not be appropriate to override the user option --
>>because, if we do, a Cygwin user may not get the line ending type that
>>they want.
>
>>
>
>I do agree with that. the other hand, libgfortran is incompatible
>with CRLF switch (that is, today, if a user specifies CRLF, gfortran
>(indepedently of where it was compiled) will not work for him. Trivial
>codes might appear to work, but any code using (for example) rewind or
>sequential direct access will be broken (see PR 23262 and duplicates).
>
>I see no way to have the Cygwin switch influence the behaviour of the
>library. the other hand, we could add a compiler switch, -fcrlf,
>which would default to -fno-crlf on non-windows systems, to -fcrlf on
>mingw and either (choice of the binaries maker) on cygwin.
>
>How do people feel about that?
>

I never have cared for the text mount options in cygwin. The only
accommodation for crlf which makes sense to me in Fortran is to treat
<crand <crlfthe same at end of record, for formatted files only, as
many other compilers do. It is extra important that gfortran be able to
make files which are neutral between Windows and linux.

FX,

Can someone accointed with cygwin experiment a bit with this patch and
give us an update on the current situation? Maybe Paul T when his NIST
patch is done?

I also have the equivalences/common/modules patch to perfect + another
that fixes PR18878 + one potential fix for PR21986. After that, I am
willing to have a go.

David, are you in a position to spend any time on it?

Regards

Paul T