This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR28585: Add Fortran 2003 NEW_LINE intrinsic function


Hello,

FX Coudert wrote:
> I'm a bit worried that not all systems supported by gfortran use \n as
> newline. E.g., i386-pc-mingw32 uses \n\r.

Sure it is "\n\r"? I thought Windows uses "\r\n". But as long as we have
to use a character(len=1) as return value, we cannot do much; besides it
makes the patch easier ;-)
In addition, the Fortran 2003 standard is explicitly saying, achar(10)
('\n') is returned, if representable in the default character set (13.7.85).


Brooks Moses wrote:
> Unfortunately, this _does_ mean that in a standard-compliant
> implementation, the following commands will produce different files on a
> system that uses \n\r as a newline -- but that's an issue with the
> standard, not with the implementation:
> 
>     WRITE(*,'A') this // NEW_LINE(this) // that
>     WRITE(*,'A') this, that

I assume you mean
   write(*,'(A)')     this // NEW_LINE(this) // that
   write(*,'(A,/,A)') this, that

The purpose of new_line() seems to be (10.6.3):
"If the file is connected for stream access, the output may be split
across more than one record if it contains newline characters. A newline
character is a nonblank character returned by the intrinsic
function NEW LINE. Beginning with the first character of the output
field, each character that is not a newline is written to the current
record in successive positions; each newline character causes file
positioning at that point as if by slash editing (the current record is
terminated at that point, a new empty record is created following the
current record, this new record becomes the last and current record
of the file, and the file is positioned at the beginning of this new
record)."

The "as if by slash editing" does not seem to be fulfilable, however.

This might be something useful for streams, even though the
platform-specific line-break is not always supported.
(What does actually MacOS use? I thought "\r", but with the change to a
FreeBSD kernel, it is now "\n"?)


> For what it's worth, I believe that the standard gcc rule of thumb
> on what can be allowed without a copyright assignment is 10 lines.
> In any case, the idea is that what's allowed are only things that
> contain insufficient new work to be copyrighted.)  This looks to
> be notably larger than that.
(I thought that it was short enough since in the .c files it was
basically copied from ACHAR.)
But ok, then we have to wait. How long do you think it usually takes?
10 September: Send email to assign at gnu.org
19 September: Confirmation email
20 September: Letter posted in Boston
23 September: Letter arrived here in Germany; I signed and sent it back
Looking at Chris emails, it might take rather long?


Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]