reading files with variable name length

[nspikito]

In a previous version of this compiler (and an older operating system) I was able to read a file with any length of name using a character*60 variable called 'name'. Any trailing blanks in the filename were ignored. Now that isn't working. The dimension of the 'name' variable has to exactly fit the length of the file name.
any suggestions?
Spike

[Steven_L_Intel1]

My guess is that there aren't trailing blanks, but perhaps trailing NULs. Trailing blanks should be ignored. If you have an example that demonstrates otherwise, send it to us at vf-support@compaq.com

Steve

[Intel_C_Intel]

Spike,

I do the same thing as you are doing and do not run into any problems with CVF 6.5a like you are describing . This works for me on NT 4.0, Windows 2000, and Windows 98, so something else must be going on.

Tom

[Intel_C_Intel]

Is it possible that when Spike says that trailing spaces in file names worked in 'a previous version of this compiler (and an older operating system)' he means MS FPS and a 16 bit OS (DOS, Win 3.1)? In that world, what he describes will work But in Win32, spaces are vaild filename characters, and so filename variables must be TRIMed.

Just a thought,
John

[Intel_C_Intel]

John,

No, this should not be a problem. A long time ago I decided that users should be able to input filenames into a program (remember having to link files with environment variables for I/O?), so all my programs have a separate filename for each I/O file that is dimensioned to CHARACTER(LEN=80). None of my programs have this problem (I still stick to 8.3 format for all I/O files, but other users have used long filenames appended to paths with no problem. So, CVF does trim trailing blanks from filenames that are read in and is able to use any length character string for a filename. As stated previously, I suspect something else is going on.

Tom

[Intel_C_Intel]

Thanks, Tom. Now that I think about it, we saw this when we moved to NT back when the compiler we used was Watcom 10.6.

Sorry for any confusion,
John