READ statement and first character is "b"

[armelle2]

Hello,

Compaq Visual Fortran Professional Edition 6.1.A (Windows 2000)

I have a problem with this little program:

Project: Fortran Console Application

Only one file :

ccccccccccccccccccccccccccccccccccccccccccccccccccc
PARAMETER(NMAXLIG=30000,INFINI=99999999)
character *16 code16
character *80 imp2(NMAXLIG)
c
do i=1,INFINI
READ(5,'(A16)') code16
write(imp2(i)(1:16),'(A16)') code16
if (code16(1:3).eq.'FIN') goto 40
end do
40 do j=1,i
write(40,'(A16)') imp2(j)(1:16)
end do
close(40)
end
cccccccccccccccccccccccccccccccccccccccccccccccccc

In Debug, 2 Breaks at the lines:

READ(5,'(A16)') code16
write(imp2(i)(1:16),'(A16)') code16

1. Run until the first break.

(no execution of the READ statement)

2. In the Dos windows, I enter from the keyboard the string ESSAI for example, without the key Return, and before the READ statement is executed. The characters don't display (it's normal).

3. Again Run until the second break. The intruction READ is executed, i see the string ESSAI in the Dos windows and the program wait the key Return to valide the input. Then, I valide with the key Return.

4. Then, the variable code16 is "bSSAI" and not "ESSAI".

The first character is always replaced by "b". Why?

This problemalso happenssometimes in release mode when i use a HID keyboard which transmits quickly entries.

Thanks.

[Steven_L_Intel1]

I have a very faint memory of a bug in CVF like this. Version 6.1 is six years old.

[armelle2]

Thank you, Steeve, for your answer.

Can you tell me if, with the 6.6 version (last version), this bug is fixed ?

With my source, can you try it following the same steps (in debug mode) ?

If

Armelle.

[armelle2]

Thank you, Steve, for your answer.

Can you tell me if, with the 6.6 version (last version), this bug is fixed ?

With my source, can you try it following the same steps (in debug mode) ?

Armelle.

Message Edited by armelle2 on 11-15-2005 06:16 AM

Message Edited by armelle2 on 11-15-2005 06:18 AM

[cacciatore]

I use CVF

[cacciatore]

Ops, clicked something wrong.

I use CVF 6.6b W98SE, and your code worked ok.
Geraldo

[Steven_L_Intel1]

Yes, the bug was fixed in a later version of CVF. It was a very odd thing that took a lot of effort to track down.

[armelle2]

Hello Geraldo and steve,

Thank you for your help. I'm happy to know that a solution exist for my problem: Update to 6.6.

Perhaps, a other possibility is to update only the RTL (Run Time Library).

I found two sites hereafter. The cause of my problem is the RTL.

http://www.cs-software.com/software/fortran/compaq/cvf_relnotes.html:

" In some cases, console typeahead input to an application would be corrupted. The underlying cause is a WIN32 bug with reading input from a console. If a user doing typeahead inputs a few characters before the call to ReadFile() (or ReadConsole()) is executed, and then types the rest of his input after (i.e., during) the call, the OS will clobber the input in the receive buffer by the number of bytes requested in the ReadFile() call. This is true for number of bytes requested less than or equal to 40. It works as expected if you ask for at least 41 bytes.
The Fortran rtl was changed at one time to specifically only request 1 byte at a time when reading from stdin. This was done to solve another problem, multiple units sharing a redirected stdin. The solution to the current typeahead problem is to change the Fortran rtl so that 1 byte at a time reads are only done for nonconsole io. The rtl will continue to read 1 byte at a time if stdin is a file or pipe, but not if stdin is specifically the console device. (cvf11307) ".

and for the download of the RTL:

http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,7161,00.html

Self-installing executable kit :

• DFORRT.DLL - Visual Fortran non-threaded run-time support
• DFORMD.DLL - Visual Fortran threaded run-time support
• FQWIN.HLP - QuickWin run-time help file
• MSVCRT.DLL - Microsoft Visual C run-time support
• OLEAUT32.DLL - Microsoft OLE Automation
• OLEPRO32.DLL - Microsoft OLE Automation
• STDOLE32.TLB - Microsoft OLE Automation

Can I install the kit VFRUN66BI.exe (new dll DFORMD and DFORRT with corrections) for my version 6.1 ? (because VFRUN61I.exehas againthe same bug).

Armelle.

[Steven_L_Intel1]

If you build your application against the DLL libraries, then yes, you could do this.

[armelle2]

Thanks steve,

Yes, it's OK now. When i build with "Use Run time Library: DLL and not static*", all is OK.

The files dforrt.dll, dformd.dll and dfdlg100.dll are more recents now in c:winntsystem32.

In C:Program FilesMicrosoft Visual StudioDF98LIB I have always the olb libraries (dforrt.LIB, dformd.LIB) and in REDIST the old Dll.

I'm not expert with the library (build, link,...)

How to create the new library with the new .dll ? because i prefere build in static* (portability of the .exeto a Windows ME for example and to be sure that therun is the same for any PC).

Armelle.

Message Edited by armelle2 on 11-16-2005 08:33 AM

[Steven_L_Intel1]

You can compile the sources specifying /libs:dll but whoever links the library will need access to dforrt.lib, which is not redistributable.

[armelle2]

Hello steve,

A simple and good solution is to put the new DFORRT.dll with the .exe (in the same directory).

Thanks again for your help and your competence (alsoto Geraldo and everybody).

Very good Forum.

Armelle.