@DEVICE failure

May 20, 2008
3,520
3
Elkridge, MD, USA
These are the pseudofilenames which @DEVICE reports to be devices when tested without an extension, e.g., %@DEVICE[AUX]:
AUX COM1 COM2 COM3 COM4 CON LPT1 LPT2 LPT3 LPT4 NUL PRN

However, when tested WITH an extension, e.g., %@DEVICE[AUX.a], the following devices are incorrectly reported (i.e., files cannot be created with such names):
AUX COM1 COM2 COM3 COM4 LPT1 LPT2 LPT3 LPT4 PRN

Only the CON and the NUL devices are reported correctly when the pseudofilename contains an extension. Prefixing the pseudofilename with a full path, e.g., %_cwd\AUX, does not alter the result. I did the test on TCC 12.10.66 and on
4NT 8.02.106. Platform: Windows XP [Version 5.1.2600].

A possibe fix: internally to TCC the @DEVICE function should use the @NAME function to strip the extension before making the test.
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
10,975
98
These are the pseudofilenames which @DEVICE reports to be devices when tested without an extension, e.g., %@DEVICE[AUX]:
AUX COM1 COM2 COM3 COM4 CON LPT1 LPT2 LPT3 LPT4 NUL PRN

However, when tested WITH an extension, e.g., %@DEVICE[AUX.a], the following devices are incorrectly reported (i.e., files cannot be created with such names):
AUX COM1 COM2 COM3 COM4 LPT1 LPT2 LPT3 LPT4 PRN

Only the CON and the NUL devices are reported correctly when the pseudofilename contains an extension. Prefixing the pseudofilename with a full path, e.g., %_cwd\AUX, does not alter the result. I did the test on TCC 12.10.66 and on
4NT 8.02.106. Platform: Windows XP [Version 5.1.2600].
Not sure why anybody would care, but your problem is with the Windows API, not TCC. I'm not going to second-guess Windows and tell it that a name is a device when Windows says it isn't.

Your example filenames are invalid for both devices AND filenames. (Did you want @DEVICE to return "maybe"?)
 
May 20, 2008
3,520
3
Elkridge, MD, USA
---- Original Message ----
From: rconn
To: [email protected]
Sent: Thursday, 2011. May 26. 14:18
Subject: RE: [Support-t-2869] Re: @DEVICE failure

| Quote:
| Originally Posted by Steve Fabian
|| These are the pseudofilenames which @DEVICE reports to be devices
|| when tested without an extension, e.g., %@DEVICE[AUX]:
|| AUX COM1 COM2 COM3 COM4 CON LPT1 LPT2 LPT3 LPT4 NUL PRN
|
|| However, when tested WITH an extension, e.g., %@DEVICE[AUX.a], the
|| following devices are incorrectly reported (i.e., files cannot be
|| created with such names):
|| AUX COM1 COM2 COM3 COM4 LPT1 LPT2 LPT3 LPT4 PRN
|
|| Only the CON and the NUL devices are reported correctly when the
|| pseudofilename contains an extension. Prefixing the pseudofilename
|| with a full path, e.g., %_cwd\AUX, does not alter the result. I did
|| the test on TCC 12.10.66 and on
|| 4NT 8.02.106. Platform: Windows XP [Version 5.1.2600].
|
| Not sure why anybody would care, but your problem is with the Windows
| API, not TCC. I'm not going to second-guess Windows and tell it that
| a name is a device when Windows says it isn't.
|
| Your example filenames are invalid for both devices AND filenames.
| (Did you want @DEVICE to return "maybe"?)

Well, why is aux.a illegal both as a device name and as a filename? This is the kind of thing for which the OP requested an "ISVALID" test. I start to think it is needed, after all!
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
10,975
98
Well, why is aux.a illegal both as a device name and as a filename? This is the kind of thing for which the OP requested an "ISVALID" test. I start to think it is needed, after all!
You seem to have the mistaken belief that if something isn't a valid filename, then it must be a valid device name.

"aux.a" is NOT a valid device name, so @DEVICE correctly returns 0. The fact that it is also an invalid filename isn't relevant here.

(BTW, it *is* possible to create files with illegal names like "aux.a", but I am *not* going to tell people how to do it!)
 
May 20, 2008
3,520
3
Elkridge, MD, USA
---- Original Message ----
From: rconn
To: [email protected]
Sent: Thursday, 2011. May 26. 17:07
Subject: RE: [Support-t-2869] Re: @DEVICE failure

| Quote:
| Originally Posted by Steve Fabian
| Well, why is aux.a illegal both as a device name and as a filename?
| This is the kind of thing for which the OP requested an "ISVALID"
| test. I start to think it is needed, after all!
|
| You seem to have the mistaken belief that if something isn't a valid
| filename, then it must be a valid device name.
|
| "aux.a" is NOT a valid device name, so @DEVICE correctly returns 0.

But why are the names CON.a and NUL.a valid device names?

| The fact that it is also an invalid filename isn't relevant here.

In fact, that is the initium for this thread. The OP wants to have a test that would determine whether or not a specific string is valid as a directory path or as a file name. Persons new to MS operating systems do not recall all the old device names, so a name like AUX.A may be a logical candidate for a filename.

| (BTW, it *is* possible to create files with illegal names like
| "aux.a", but I am *not* going to tell people how to do it!)

I don't think anyone active in this thread would be interested, anyway.
--
Steve
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,827
48
Albuquerque, NM
prospero.unm.edu
But why are the names CON.a and NUL.a valid device names?
I'm told this was originally to facilitate very early command-line compilers and linkers and so on, which would accept a base filename on the command line and automatically append the relevant extensions. If you supplied a device name like NUL, the compiler (linker, etc.) would generate output filenames like NUL.LIB, NUL.COM, and so forth -- which would still go to the desired device.
 
May 30, 2008
215
1
I'm told this was originally to facilitate very early command-line compilers and linkers and so on, which would accept a base filename on the command line and automatically append the relevant extensions. If you supplied a device name like NUL, the compiler (linker, etc.) would generate output filenames like NUL.LIB, NUL.COM, and so forth -- which would still go to the desired device.
Interesting.

Backwards compability, the reason for most strange (mis)features in Windows!

(Not that I'm complaining)