[PATCH] gfortran.dg/pr32627.f03 prints nul byte

[PATCH] gfortran.dg/pr32627.f03 prints nul byte

[Martin Sebor]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

We've been debugging a problem where nul (and other control)
characters have been randomly appearing in powerpc parallel
build logs. In the process, I noticed that some of the nuls
are readily reproducible. One such case is due to
the pr32627.f03 test which verifies that Fortran programs
can initialize character arrays from C strings. The test
declares an array as big as the C string (including the
terminating nul) and prints its value to stdout. This then
causes the nul to appear in the log files.

The attached patch changes the declaration of the Fortran
array to match the number of non-nul characters. Tested on
powerpc64.

Martin

[-- Attachment #2: gcc-pr32627.f03-nul.patch --]
[-- Type: text/x-patch, Size: 607 bytes --]

2015-04-09  Martin Sebor  <msebor@redhat.com>

	* gfortran.dg/pr32627.f03 (strptr): Change size to match the number
	of non-nul characters.

diff --git a/gcc/testsuite/gfortran.dg/pr32627.f03 b/gcc/testsuite/gfortran.dg/pr32627.f03
index f8695e0..d9e2b13 100644
--- a/gcc/testsuite/gfortran.dg/pr32627.f03
+++ b/gcc/testsuite/gfortran.dg/pr32627.f03
@@ -18,7 +18,7 @@ program main
   type( c_ptr )               :: x
   type( A ), pointer          :: fptr
   type( A ), target           :: my_a_type
-  character( len=9 ), pointer :: strptr
+  character( len=8 ), pointer :: strptr
 
   fptr => my_a_type
 

Re: [PATCH] gfortran.dg/pr32627.f03 prints nul byte

[Martin Sebor]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

Attached is an updated patch that fixes the substr_6.f90
test that also prints a nul character to stdout. I don't
think there are any others.

Besides interfering with the debugging of the log corruption
I mentioned, printing nuls or control characters in tests is
also problematic for tools designed to post-process log files
(e.g., grep) that are intended to work with text files (i.e.,
files not containing nuls). Control characters can cause the
tools to fail in non-C locales (such as UTF-8).

On 04/09/2015 12:54 PM, Martin Sebor wrote:
> We've been debugging a problem where nul (and other control)
> characters have been randomly appearing in powerpc parallel
> build logs. In the process, I noticed that some of the nuls
> are readily reproducible. One such case is due to
> the pr32627.f03 test which verifies that Fortran programs
> can initialize character arrays from C strings. The test
> declares an array as big as the C string (including the
> terminating nul) and prints its value to stdout. This then
> causes the nul to appear in the log files.
>
> The attached patch changes the declaration of the Fortran
> array to match the number of non-nul characters. Tested on
> powerpc64.
>
> Martin


[-- Attachment #2: gcc-fortran-nul.patch --]
[-- Type: text/x-patch, Size: 1270 bytes --]

2015-04-09  Martin Sebor  <msebor@redhat.com>

	* gfortran.dg/pr32627.f03 (strptr): Change size to match the number
	of non-nul characters.
	* gfortran.dg/substr_6.f90: Make the NUL character visible on stdout
	and avoid corrupting text output.

diff --git a/gcc/testsuite/gfortran.dg/pr32627.f03 b/gcc/testsuite/gfortran.dg/pr32627.f03
index f8695e0..d9e2b13 100644
--- a/gcc/testsuite/gfortran.dg/pr32627.f03
+++ b/gcc/testsuite/gfortran.dg/pr32627.f03
@@ -18,7 +18,7 @@ program main
   type( c_ptr )               :: x
   type( A ), pointer          :: fptr
   type( A ), target           :: my_a_type
-  character( len=9 ), pointer :: strptr
+  character( len=8 ), pointer :: strptr
 
   fptr => my_a_type
 
diff --git a/gcc/testsuite/gfortran.dg/substr_6.f90 b/gcc/testsuite/gfortran.dg/substr_6.f90
index 813a025..a7cdc10 100644
--- a/gcc/testsuite/gfortran.dg/substr_6.f90
+++ b/gcc/testsuite/gfortran.dg/substr_6.f90
@@ -11,6 +11,15 @@ if (c(1) /= "     ") call abort()
 c = (/ c0(1)(1:5) /)
 do i=1,5
    if (c(1)(i:i) /= c1(i)) call abort()
+
+   ! Make NULs visible (and avoid corrupting text output).
+   if (c(1)(i:i) == ACHAR(0)) then
+    print "(a,$)", "<NUL>"
+  else
+    print "(a,$)", c(1)(i:i)
+  end if
 end do
-print *, c(1)
+
+print *, ""
+
 end

Re: [PATCH] gfortran.dg/pr32627.f03 prints nul byte

[msebor]

Ping. Is this patch okay for trunk?

On 04/09/2015 03:16 PM, Martin Sebor wrote:
> Attached is an updated patch that fixes the substr_6.f90
> test that also prints a nul character to stdout. I don't
> think there are any others.
>
> Besides interfering with the debugging of the log corruption
> I mentioned, printing nuls or control characters in tests is
> also problematic for tools designed to post-process log files
> (e.g., grep) that are intended to work with text files (i.e.,
> files not containing nuls). Control characters can cause the
> tools to fail in non-C locales (such as UTF-8).
>
> On 04/09/2015 12:54 PM, Martin Sebor wrote:
>> We've been debugging a problem where nul (and other control)
>> characters have been randomly appearing in powerpc parallel
>> build logs. In the process, I noticed that some of the nuls
>> are readily reproducible. One such case is due to
>> the pr32627.f03 test which verifies that Fortran programs
>> can initialize character arrays from C strings. The test
>> declares an array as big as the C string (including the
>> terminating nul) and prints its value to stdout. This then
>> causes the nul to appear in the log files.
>>
>> The attached patch changes the declaration of the Fortran
>> array to match the number of non-nul characters. Tested on
>> powerpc64.
>>
>> Martin
>

Re: [PATCH] gfortran.dg/pr32627.f03 prints nul byte

[Jeff Law]

On 04/17/2015 11:51 AM, msebor@redhat.com wrote:
> Ping. Is this patch okay for trunk?
Yes, both are OK for the trunk.

Sorry for the delay, we're really just getting started working through 
stuff that was queued up for stage1.


jeff