@DEVICE failure

[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].

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

 

[rconn]

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"?)

 

[Steve Fabian]

---- Original Message ----
From: rconn
To: ESFabian@zenge.org
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]

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!)

 

[Steve Fabian]

---- Original Message ----
From: rconn
To: ESFabian@zenge.org
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

 

[rconn]

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

Ask Microsoft; it's their API and filesystem.

 

[Charles Dye]

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.

 

[nikbackm]

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)