If and Iff inconsistency...

[mathewsdw]

I'm not sure where to post this, it's just a reference to a minor bug in batch processing that I do know how to work around. However, in my own programming my goal is to eliminate all bugs, whether or not there is a simple workaround for them.

To start, a batch file with the given lines:

@Echo Off
If 1 @Echo One One
Iff 1 Then
@Echo One Two
EndIff
If 9 @Echo Nine One
Iff 9 Then
@Echo Nine Two
EndIff
If 0 @Echo Zero One
Iff 0 Then
@Echo Zero Two
EndIff

Output from above batch file:

Z:\BadSample.bat [2] Usage : IF [/I] [NOT] condition [.AND. | .OR. | .XOR. [NOT] condition ...]
One Two
Z:\BadSample.bat [6] Usage : IF [/I] [NOT] condition [.AND. | .OR. | .XOR. [NOT] condition ...]
Nine Two
Z:\BadSample.bat [10] Usage : IF [/I] [NOT] condition [.AND. | .OR. | .XOR. [NOT] condition ...

Bottom line: For the "IFF" statement, a value of zero is "false" and any non-zero value is "true", whereas for the "IF" statement there has to be an honest to goodness conditional expression such as "0 != 1" (true) or "1 == 0" (false). Just reporting a minor (kind of weird, I must admit!:)) inconsistency...

 

[Steve Fabian]

mathewsdw wrote:
...
| Bottom line: For the "IFF" statement, a value of zero is "false" and
| any non-zero value is "true", whereas for the "IF" statement there
| has to be an honest to goodness conditional expression such as "0 !| 1" (true) or "1 == 0" (false). Just reporting a minor (kind of
| weird, I must admit!:)) inconsistency...

You found an undocumented extension. It might work in other commands
where a conditional expression is expected, and it might not. As you know,
the only documented form is a conditional expression, with a logical value,
not a number.
--
Steve

 

[rconn]

WAD (and definitely not a bug).

IF is required to be 100% compatible with the IF in CMD.EXE, which requires a conditional expression.

IFF is a TCC-only command, and can be a bit smarter about parsing the line when the user enters invalid syntax (as you did).

 

[Steve Fabian]

rconn wrote:

| WAD (and definitely not a bug).
|
| IF is required to be 100% compatible with the IF in CMD.EXE, which
| requires a conditional expression.
|
| IFF is a TCC-only command, and can be a bit smarter about parsing
| the line when the user enters invalid syntax (as you did).

Do other command forms, such as @IF[] and DO WHILE, which use
conditional expressions, also consider any numeric expression TRUE unless
its value is zero? If so, this would be a good item to document. IIRC this
had been requested long ago.
--
Steve

 

[rconn]

Do other command forms, such as @IF[] and DO WHILE, which use
conditional expressions, also consider any numeric expression TRUE unless
its value is zero? If so, this would be a good item to document. IIRC this
had been requested long ago.

Every command and variable function in TCC uses the same conditional expression evaluator. This syntax is not documented because the parser is only able to decipher the bad syntax in some cases. So IMO it would be a BAD item to document!

 

[mathewsdw]

WAD (and definitely not a bug).

IF is required to be 100% compatible with the IF in CMD.EXE, which requires a conditional expression.

Thanks for the explanation! That makes sense! However, since the IFF command accepts it, I question whether it is really valid to call it "invalid syntax"! (BTW, I every language I use (and I don't use CMD.EXE's batch language any more since your products) does consider any non-zero numeric value "true", and a zero numeric value "false". And is this an extension to CMD.EXE's processing that would cause any problems??? Extensions don't, in my opinion, render something not 100% compatible.)

 

[rconn]

Thanks for the explanation! That makes sense! However, since the IFF command accepts it, I question whether it is really valid to call it "invalid syntax"! (BTW, I every language I use (and I don't use CMD.EXE's batch language any more since your products) does consider any non-zero numeric value "true", and a zero numeric value "false". And is this an extension to CMD.EXE's processing that would cause any problems??? Extensions don't, in my opinion, render something not 100% compatible.)

It's definitely valid to call it "invalid syntax", because:

1) The TCC parser is not able to determine 100% of the time (depending on exactly what follows the single argument) that you failed to provide the full conditional expression; and

2) It's sloppy coding, which makes your code less readable and maintainable; and

3) It provides no benefit, so it fails to qualify as a "feature".

If this was documented as a feature, I'd promptly be deluged with "bug" reports complaining that it works if they use one type of invalid syntax, but fails if they use another!

 

[Steve Fabian]

mathewsdw wrote:

| ---Quote (Originally by rconn)---
|| WAD (and definitely not a bug).
||
|| IF is required to be 100% compatible with the IF in CMD.EXE, which
|| requires a conditional expression.
| ---End Quote---
|
| Thanks for the explanation! That makes sense! However, since the IFF
| command accepts it, I question whether it is really valid to call it
| "invalid syntax"!

Yes, I agree in principle - if it would be unambiguous. However, as Rex
noted, the parser is not always able to determine whether or not the value
of an expression is numeric. This could cause inconsistency, hence the
"invalid syntax",

| (BTW, I *every* language I use (and I don't use
| CMD.EXE's batch language any more since your products) *does*
| consider any non-zero numeric value "true", and a zero numeric value
| "false".

Obviously you use only languages which are strongly influenced by C.
Most other languages, including programming languages Algol, Basic, Cobol,
Fortran, Lisp, Pascal, PL/1, PL/M, and command processing language DCL (used
by VMS / OpenVMS) distinguish between three types of data - numeric,
character, and logical, and do not intermix them.

| And is this an extension to CMD.EXE's processing that would
| cause any problems??? Extensions don't, in my opinion, render
| something not 100% compatible.)

If Language 1 and Language 2 are to be 100% compatible, anything
reported as an error by a language processor for one of them must be
reported by the language processor for the other, else you could not use one
to validate code intended for the other. Extensions are not permitted. It's
the reason many compilers have options to enforce a specific dialect of
their subject language, e.g., ANSI C 1989, or ANSI FORTRAN 1977.
--
Steve

 

[mathewsdw]

Yes, I agree in principle - if it would be unambiguous. However, as Rex noted, the parser is not always able to determine whether or not the value of an expression is numeric. This could cause inconsistency, hence the "invalid syntax".

Beating a dead horse: It is true that the only three languages I have used for the past several years have been C++ and Rex's batch language and (very little, and not very recently) Visual Basic. However, I was once a mainframe programmer, and in fact I did use (at one time or another) Cobol, Fortran, PL/I (as well as CLIST, REXX, and IBM mainframe macro assembler (BAL)), and my recollection is that at least some of them (although I will fully admit that I haven't used any of them for years) used the same rule: non-zero is "true" and zero "false". (I believe, but again I could be wrong, that Visual Basic also followed the same rule. Even though I have Visual Basic 2008 installed on this machine, I haven't used it in quite a while and when I tried to run it to test this proposition, I got a bunch of "System.something could not be found." error messages and, since I no longer use it (it (and all other languages) has been totally replaced by C++ and Rex's batch language) I don't really care so I'm not going to take the time to investigate this any further. However, I will note that statements such as "If 1 then" did not produce any error messages, although the missing "System" things may have caused it to not get that far in analyzing the code.

Obviously you use only languages which are strongly influenced by C. Most other languages, including programming languages Algol, Basic, Cobol, Fortran, Lisp, Pascal, PL/1, PL/M, and command processing language DCL (used by VMS / OpenVMS) distinguish between three types of data - numeric, character, and logical, and do not intermix them. If Language 1 and Language 2 are to be 100% compatible, anything reported as an error by a language processor for one of them must be reported by the language processor for the other, else you could not use one to validate code intended for the other. Extensions are not permitted. It's the reason many compilers have options to enforce a specific dialect of their subject language, e.g., ANSI C 1989, or ANSI FORTRAN 1977.

I totally disagree with that on principle (and it is, in fact, obviously not true or otherwise languages would be unable to “evolve” over time - new syntax/functionality would almost certainly be reported as an error in a compiler for a previous version of the language), and the fact that this is only supported with a compiler switch kind of supports my opinion. Why would anyone work on code in one compiler that was intended for another (older) compiler??? And I think the primary reason options such as "ANSI C 1989" are provided is to allow one to work on code written for a prior version of the compiler/language to compile/run in the more-current version of the compiler without errors due to incompatibilities in the newer version of the language with code written for the older version of the language, and in my own case, whenever this happened I changed the code to match the newer, current, version of the language rather than applying some compiler switch to force compatibility with older versions of the language. (I can't help but think that not doing that is like trying to walk in chains.) But, again, this is beating dead horse, it is as it is and will (almost certainly!) never be changed

And, as a final note, while I haven’t checked this lately, when I started this approach (zero vs. non-zero) it produced slightly smaller executables. Not enough to be really significant, but I like smaller executables, and it’s also less typing and I do not believe it to be at all hard to understand. I will also admit that I haven’t checked this for many years, and I’m frankly too lazy to check it now because it is something I do automatically (without thinking about it at all), and it is harmless, at least in C++. (I don’t think of “if” conditions as “if (something is true)”, I think about them as “if (something is non-zero)”.)
<O:p

 

[rconn]

The fatal flaw in your argument is that the languages that do support this type of syntax also mandate specific delimiters (for example, the left and right parentheses in C/C++).

I could also mandate delimiters; the drawback is that somebody's going to have to change a few hundred billion batch files and aliases to accommodate the new syntax. (Well, and the other drawback is that TCC users will never be able to run a third-party batch file.)