linker problems with short filenames in command files

Put the "test~1.obj" in quotes.  Without the quotes, the linker tries to parse it like any other expression in the linker command file.  With the quotes, the linker passes the file name to the OS, where it is correctly interpreted.

Thanks and regards,

-George

I know that putting the filename in quotes is a workround in specific cases, but the linker command file in question is computer-generated and adding the quotes is not going to be possible.

It is clearly a mistake that there are two different interpretations of filenames: one for command lines and one for command files.

I suspect the problem is not a design decision but an unforseen side-effect of adding ~ as an operator. As this operator is limited to "Memory range origin and length" (according to the documentation), a reasonable parser should have no difficulty in distinguishing a constant (where the ~ can only be the first character) and ~ as part of a valid (and surprisingly-common) filename.

This is a completely different case from spaces in filenames, as it has always been impossible to use such a name without quotes. I know of no other cases where filenames with ~ have to be enclosed in quotes.

The correct response would be to fix the linker.

Peter Robertson said:

As this operator is limited to "Memory range origin and length"

That is incorrect.  Memory range origin and length are, in older toolsets, strictly limited to constants.  This bit of documentation is saying that you can now write expressions in place of those constants, and those expressions can use many operators, ~ among them.  There are many other places where ~ may appear.  For instance ...

sym1 = sym2 & ~0xff;  /* contrived, but possible */

Thus, it is not surprising that the linker gets confused when you try to use ~ as part of a file name.  Using quotes is one alternative.  Another is to use the full long name of the file.

Thanks and regards,

-George

~ is a unary operator. This means it only ever appears at the start of an expression (or subexpression) or after
another operator. The only way that accepting ~ in a filename would cause parsing problems would be if you could
ever validly have "<alphanumeric>~" where the ~ is a operator. As there are no alphanumeric operators I see
nowhere in the linker command file syntax where this is so.

This means that there appears to be no valid reason for rejecting valid filenames other than as an artefact of a
poor design of the command file parser. Resolving this by putting the burden on users to take special action is
not impressive.

Your suggestion of using quotes or avoiding short filenames is of no help when the valid filenames are being
generated automatically.