experchange > fortran

David Duffy (02-15-19, 02:37 AM)
By accident (the context was copying a C string to a Fortran
string), I had been trying to apply a format statement
to writing a partially filled uninitiated string, which worked,
kinda.

program example
character (len=10), dimension(2) :: strings
strings(1)(1:1)='A'
strings(2)(1:4)='BCDE'
write(*,'(i2,1x,a,a10,a)') len(strings(1)), ' "', strings(1), '"'
write(*,'(i2,1x,a,a10,a)') len(strings(2)), ' "', strings(2), '"'
end program example

10 "A"
10 "BCDE"

Not quite what I expected, though I also managed to get (with another
compiler running under valgrind)

10 "A????"
10 "BCDE?"

Cheers, David Duffy.

Actual project was reading dirent structure, which now works beautifully on
linux and mac:
call list_files(dir, files=files, filetypes=filetypes, inodes=inodes)
nfiles=size(files)
do i=1, nfiles
inquire(file=trim(dir) // '/' // files(i), size=siz)
write(*,'(a,1x,a1,1x,i12,1x,i12)') files(i), filetypes(i), inodes(i), siz
end do
gah4 (02-15-19, 03:31 AM)
On Thursday, February 14, 2019 at 4:37:49 PM UTC-8, David Duffy wrote:
[..]
> 10 "BCDE"
> Not quite what I expected, though I also managed to get (with another
> compiler running under valgrind)


It might have null characters after the name, which might not print
on your system. I don't know if you used copy/paste above, but
there don't seem to be null characters there.

(or maybe other non-printing characters.)
dpb (02-15-19, 03:51 AM)
On 2/14/2019 6:37 PM, David Duffy wrote:
[..]
> 10 "BCDE"
> Not quite what I expected, though I also managed to get (with another
> compiler running under valgrind) ....


Only first and first four characters are initialized; remaining is
(probably) zero-filled by the compiler on allocation and then the i/o
rtl tries to do you a favor by acting like C and terminating when it
does find the null.

One of the TRANSFER() or EQUIVALENCE tricks should be able to show you
what the content of the remainder of the allocated memory space is; I'm
betting it's zero-filled.
baf (02-15-19, 08:10 AM)
On 2/14/2019 5:51 PM, dpb wrote:
> On 2/14/2019 6:37 PM, David Duffy wrote:
> ...
> Only first and first four characters are initialized; remaining is
> (probably) zero-filled by the compiler on allocation and then the i/o
> rtl tries to do you a favor by acting like C and terminating when it
> does find the null.
> One of the TRANSFER() or EQUIVALENCE tricks should be able to show you
> what the content of the remainder of the allocated memory space is; I'm
> betting it's zero-filled.
> --


As was suggested, the remaining "extra" spaces were filled with null and
other garbage characters depending on the OS. Try the modified version
of your program to see what you are missing.

program example
character (len=10), dimension(2) :: strings
strings(1)(1:1)='A'
strings(2)(1:4)='BCDE'
write(*,'(i2,1x,a,a10,a)') len(strings(1)), ' "', strings(1), '"'
write(*,"(*(i0,:','))")(iachar(strings(1)(i:i)),i= 1,len(strings(1)))
write(*,'(i2,1x,a,a10,a)') len(strings(2)), ' "', strings(2), '"'
write(*,"(*(i0,:','))")(iachar(strings(2)(i:i)),i= 1,len(strings(2)))
end program example
gah4 (02-15-19, 09:38 AM)
On Thursday, February 14, 2019 at 10:10:03 PM UTC-8, baf wrote:

(snip on printing undefined characters in strings)

> As was suggested, the remaining "extra" spaces were filled with null and
> other garbage characters depending on the OS. Try the modified version
> of your program to see what you are missing.


> program example
> character (len=10), dimension(2) :: strings
> strings(1)(1:1)='A'
> strings(2)(1:4)='BCDE'
> write(*,'(i2,1x,a,a10,a)') len(strings(1)), ' "', strings(1), '"'
> write(*,"(*(i0,:','))")(iachar(strings(1)(i:i)),i= 1,len(strings(1)))
> write(*,'(i2,1x,a,a10,a)') len(strings(2)), ' "', strings(2), '"'
> write(*,"(*(i0,:','))")(iachar(strings(2)(i:i)),i= 1,len(strings(2)))
> end program example


I would have used Z2 format, but otherwise.

Which still doesn't say if the null characters aren't being
output, or our and we just don't see them.

For a test, there are some null characters between quotes: ""
dpb (02-15-19, 02:55 PM)
On 2/15/2019 1:38 AM, gah4 wrote:
> On Thursday, February 14, 2019 at 10:10:03 PM UTC-8, baf wrote:
> (snip on printing undefined characters in strings)
> I would have used Z2 format, but otherwise.
> Which still doesn't say if the null characters aren't being
> output, or our and we just don't see them.


I'm betting the i/o rtl with the A FORMAT just acts like C (because it
probably is the C rtl that gets called eventually, anyway) and stops
when it reaches the null.

You could prove this by doing the write to a file and then looking at
the content of the file.

> For a test, there are some null characters between quotes: "


But those had to have been initialized and are now "real" characters in
the allocated string--a wholly different case.

I'm not positive what the Standard actually says is supposed to happen
here; the vendor doc I typically rely on for practical understanding
that usually is pretty clear happens to be mute on this particular topic
in never addressing it with example/comment and I don't have the time at
the moment to dig in the actual Standard doc itself, sorry.
mecejfour (02-15-19, 03:00 PM)
On Fri, 15 Feb 2019 00:37:44 +0000, David Duffy wrote:

[..]
> 10 "A????"
> 10 "BCDE?"
> Cheers, David Duffy.


You may find it helpful to run your program with the command

gfortran -finit-character=36 dd.f90

The output:

10 "A$$$$$$$$$"
10 "BCDE$$$$$$"

You cam replace '36', which asks for '$', with the ASCII character code
for another character if you wish.

--mecej4
Ron Shepard (02-15-19, 06:56 PM)
On 2/15/19 6:55 AM, dpb wrote:
> But those had to have been initialized and are now "real" characters in
> the allocated string--a wholly different case.
> I'm not positive what the Standard actually says is supposed to happen
> here; the vendor doc I typically rely on for practical understanding
> that usually is pretty clear happens to be mute on this particular topic
> in never addressing it with example/comment and I don't have the time at
> the moment to dig in the actual Standard doc itself, sorry.


Whether the string has nulls or some other nonprinting character, the
standard does not say what happens. That is because historically it was
common to allow formatted output of some nonprinting characters in order
to control output devices. You could do such things as position the
cursor on a display screen by sending specific sequences of nonprinting
characters. So the standard committee did not want to forbid that
practice, while at the same time it had no business trying to
standardize them either. Fortran had already been bitten by writing
standard ASA printer control sequences into the early fortran standards,
and by the time of f77 that had already become outdated, so they chose
not to do that with ASCII. Also historically, there have always been a
plethora of vendor specific character sets in use by fortran compilers,
so the standard committee attempted to remain agnostic on those too. It
wasn't until f90, almost three decades after the first standard, that
the ASCII intrinsics ACHAR() and IACHAR() were added.

Even in a specific compiler, you will get different results with
different compiler options, and you will get different run time results
depending on whether the memory for the variable is statically allocated
or allocated from the stack or the heap. So if it matters in your
program, you should initialize/assign everything yourself to valid values.

$.02 -Ron Shepard
dpb (02-15-19, 10:00 PM)
On 2/15/2019 10:56 AM, Ron Shepard wrote:
[..]
> or allocated from the stack or the heap. So if it matters in your
> program, you should initialize/assign everything yourself to valid values.
> $.02 -Ron Shepard


I was almost positive that was the case but not _quite_ confident-enough
to just say so! :)
gah4 (02-16-19, 02:10 AM)
On Friday, February 15, 2019 at 8:56:29 AM UTC-8, Ron Shepard wrote:

(snip)

[..]
> so the standard committee attempted to remain agnostic on those too. It
> wasn't until f90, almost three decades after the first standard, that
> the ASCII intrinsics ACHAR() and IACHAR() were added.


My first guess was that the program was writing out invisible
NUL characters, not noticed by the OP.

In a previous post, I put actual NUL characters, using paste
into a browser window, to test the effect. In the window that
I pasted them, they appeared as open rectangles. After the post
went through, they came out as blanks.

(OS X has the pbcopy command, such that you can write directly
into the paste buffer. The command-V in the appropriate place.)

As others have noted, NUL is special in C, and in some places
unrelated (or less directly related) to C.

In addition, for security reasons, it might be that some control
characters can't be used in newsgroup posts.

In the Fortran 66 days, padding with blanks was usual.
For example, input in A1 format would blank pad the rest of
the characters (if any) in the data item. That isn't so obvious
in the case of CHARACTER variables.
robin.vowels (02-16-19, 03:44 AM)
On Friday, February 15, 2019 at 11:37:49 AM UTC+11, David Duffy wrote:
[..]
> end program example
> 10 "A"
> 10 "BCDE"


Both strings are not initialised. Results are undefined.
You need to initialize every character
[..]
Spiros Bousbouras (02-19-19, 11:37 PM)
On Fri, 15 Feb 2019 16:10:46 -0800 (PST)
gah4 wrote:
> My first guess was that the program was writing out invisible
> NUL characters, not noticed by the OP.
> In a previous post, I put actual NUL characters, using paste
> into a browser window, to test the effect. In the window that
> I pasted them, they appeared as open rectangles. After the post
> went through, they came out as blanks.
> (OS X has the pbcopy command, such that you can write directly
> into the paste buffer. The command-V in the appropriate place.)


If one suspects that an application emits non printable characters ,
then , instead of copying and pasting them and trying to deduce from
the visual appearance what's happening , they would get more information
by either

* putting the output in a file and examining the file with a text editor.
Any decent text editor (or pager like less) will have have some special
notation to display non printable characters.

* On a Unix system pipe the output to a command which will print the values
of the bytes , for example
a.out | od -A n -t u1

> As others have noted, NUL is special in C, and in some places
> unrelated (or less directly related) to C.
> In addition, for security reasons, it might be that some control
> characters can't be used in newsgroup posts.


The only control characters which can reliably be used unencoded in usenet
posts are the <carriage return , linefeed> sequence and tabs. But a usenet
post can be encoded with quoted-printable or base64 in which case all
octets are permitted. But some people use newsreaders which are buggy or very
old and won't handle correctly such encodings.
gah4 (02-20-19, 02:23 AM)
On Tuesday, February 19, 2019 at 1:37:44 PM UTC-8, Spiros Bousbouras wrote:

(snip, I wrote)

> > In a previous post, I put actual NUL characters, using paste
> > into a browser window, to test the effect. In the window that
> > I pasted them, they appeared as open rectangles. After the post
> > went through, they came out as blanks.


(snip)

> If one suspects that an application emits non printable characters ,
> then , instead of copying and pasting them and trying to deduce from
> the visual appearance what's happening , they would get more information
> by either (snip)


> The only control characters which can reliably be used unencoded in usenet
> posts are the <carriage return , linefeed> sequence and tabs. But a usenet
> post can be encoded with quoted-printable or base64 in which case all
> octets are permitted. But some people use newsreaders which are buggy or very
> old and won't handle correctly such encodings.


Yes. I was doing an experimental test to see what happens if I
put NUL characters in a post. Different news clients or servers
might handle them differently, though.

I have known tabs to come through.

The OP could have tested for NUL, but as far as I know, didn't.
Similar Threads