[Codescan] Guard file-type suffix checks for short input names

[Stardust0831]

Global scan provenance

This issue was found by the Codex global repository scan of non-unit-test files in Stardust0831/Multiwfn, pinned to commit d2b770a531eb7039153198d04520b5992f15c49d.

Problem

readinfile() computes the trimmed input length and immediately evaluates suffix substrings that require at least three or four characters:

Multiwfn/fileIO.f90

Lines 1 to 25 in d2b770a

	!!--------- Use suitable routine to read in the file, infomode=0/1 show/don't show info
	subroutine readinfile(thisfilename,infomode)
	use defvar
	use util
	implicit real*8 (a-h,o-z)
	character(len=*) thisfilename
	character fchname*200,moldenname*200,c80tmp*20,filenameonly*200
	integer infomode,inamelen
	call path2filename(thisfilename,filenameonly) !Remove folder part
	iresinfo=0 !First assume residue information is not available from input file (but will set to 1 in the subroutine of loading pdb/pqr/gro)
	inamelen=len_trim(thisfilename)
	if (infomode==0) write(*,*) "Please wait..."
	if (thisfilename(inamelen-2:inamelen)=="fch".or.thisfilename(inamelen-3:inamelen)=="fchk"&
	.or.thisfilename(inamelen-3:inamelen)=="FCH".or.thisfilename(inamelen-3:inamelen)=="FChk"&
	.or.thisfilename(inamelen-3:inamelen)=="FCHK") then
	call readfch(thisfilename,infomode)
	else if (thisfilename(inamelen-3:inamelen)=="mwfn") then
	call readmwfn(thisfilename,infomode)
	else if (thisfilename(inamelen-2:inamelen)=="wfn".or.thisfilename(inamelen-2:inamelen)=="WFN") then
	call readwfn(thisfilename,infomode)
	else if (thisfilename(inamelen-2:inamelen)=="wfx".or.thisfilename(inamelen-2:inamelen)=="WFX") then
	call readwfx(thisfilename,infomode)

For an existing file entered with a one- or two-character relative name, expressions such as thisfilename(inamelen-3:inamelen) have a zero or negative lower bound. Bounds-checked Fortran builds terminate with a substring-bounds error; unchecked builds have undefined behavior before Multiwfn can report an unsupported file type.

Impact

Valid filesystem names such as a or x1, when entered relative to the current directory, can crash the input dispatcher. The issue also makes malformed or empty programmatic inputs unsafe to handle.

Suggested direction

• Extract and normalize the filename once, then guard its length before every suffix comparison.
• Prefer a helper that returns a lower-cased extension without direct negative-offset slicing.
• Treat empty and extensionless names as an ordinary unsupported-format error.
• Add functional cases for empty, one-character, two-character, extensionless and mixed-case filenames under bounds checking.