Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD SET problem - array element initialization

May
3,515
5
Attempting to initialize a valid array element, with a space-padded array index, fails.
Tested in TCC 11 and 14.02.35.
Note the space character after the [ below.

Assume array is defined using SETARRAY.
Code:
set array[ 0]=0
reports "Invalid array argument (out of bounds)..."
 
Illegal syntax != a bug.

The parser cannot blindly assume that all spaces in variables are meaningless. Is there an external overriding reason you can't use the correct syntax?
Where is the illegality of this syntax documented? Unless this restriction in indexing array elements is documented, it is a valid assumption that one can set (or reference the value of) an array element using leading space.

I now noticed another restriction - unlike almost anywhere else, one cannot use a hexadecimal value for the array index, the x of the 0x prefix is considered a field separator, hence the index is considered zero 0 regardless of the actual value.

The main reason (and only one in the test case) to use leading space in the array index of SET commands is vertical alignment of code listing for readability.

IMHO both of these restrictions are bugs unless documented. Once documented we just have to grin and bear it...
 
BTW, the [ character is not valid in a variable (or array) name, it terminates the variable name, and indicates the next field in the command is an array index, which must resolve to a numeric value. With a little more effort the parser could accept any expression with a numeric value, leading space or 0x included (though I would not expect it to attempt to perform the functions of an implied @EVAL no matter how nice it would be).
 
Not correct -- the [ character is valid (albeit dumb) in a variable name.

I could check for that in SET if:

(1) nobody cared about CMD compatibility
(2) Nobody cared about existing batch file / alias compatibility, and
(3) If SET had its own private parser -- but it doesn't. I don't think it is of benefit to have every command parse its arguments differently.
 
Where is the illegality of this syntax documented? Unless this restriction in indexing array elements is documented, it is a valid assumption that one can set (or reference the value of) an array element using leading space.

That's just silly -- it's not possible to document the infinite number of ways to do something wrong. The documentation shows the correct syntax; you cannot invent an undocumented variation and then insist it is a bug if the parser doesn't correctly interpret your variation. (Why then not allow spaces in command names or unquoted filenames?)

A space is a syntactically meaningful character; it is not reasonable to insist it be ignored some places and interpreted as a separator in others.

I now noticed another restriction - unlike almost anywhere else, one cannot use a hexadecimal value for the array index, the x of the 0x prefix is considered a field separator, hence the index is considered zero 0 regardless of the actual value.

A hex value can be used in a limited number of places (certainly not "almost anywhere"), and it is documented in those places.
 
The main reason (and only one in the test case) to use leading space in the array index of SET commands is vertical alignment of code listing for readability.

IMHO, left padding with 0s looks even better (and it works).
 
For those of us accustomed to leading zero 0 in a constant to mean octal this is not transparent... But it is not the case in TCC, so I agree, and it even has the advantage that its width is the same even in proportional fonts as that of any other decimal digit, so it improves vertical alignment...
 
For those of us accustomed to leading zero 0 in a constant to mean octal this is not transparent... But it is not the case in TCC, so I agree, and it even has the advantage that its width is the same even in proportional fonts as that of any other decimal digit, so it improves vertical alignment...
I have only seen such octal notation with a leading'\', as in '\015\012' for a newline. Is there anywhere where the '0' is actually leading?
 
I have only seen such octal notation with a leading'\', as in '\015\012' for a newline. Is there anywhere where the '0' is actually leading?

CMD.EXE, for one; in SET /A. (The horror.... the horror....)
 

Similar threads

Replies
4
Views
2K
Back
Top