JWASM doesn't throw error when using "name" as variable name in data definition

[bugthis]

In JWASM i can do this:

Code Select Expand

.model small, C
.stack 128
.data
  car LABEL BYTE
  name DB "Supercar$"  ; this should not be allowed and throw an error

.code
START:
  MOV AX, @DATA
  MOV DS, AX
  MOV DX, OFFSET car
  MOV AH, 09h
  INT 21h
  MOV AH, 4Ch
  INT 21h
END START

1. The code compiles without errors.
2. If you run it, it outputs garbage the label car points to. Because the string "supercar$" isn't
compiled in the code, because name is not a valid variable name.
3. It doesn't output garbage, if you add a valide variable with a string before or after the invalid variable name.

sth. like this:

Code Select Expand

.data
  car LABEL BYTE
  name DB "Supercar$"  ; this should not be allowed and throw an error
  validname DB "YESYESYES$"
...
This will print:

Code Select Expand

YESYESYES
and end.

JWASM version is v2.14 from Dec 20 2020.

MASM v5.10 prints at least a warning message:

Code Select Expand

name.ASM(9): warning A4001: Extra characters on line
...
1 Warning Errors
The resulting object code can be linked to a working EXE file. The output is the same.

[NoCforMe]

That example would assemble, link and run correctly using MASM ...

[bugthis]

That example would assemble, link and run correctly using MASM ...

Didn't you read what i wrote?

[NoCforMe]

Missed that. My bad.

[zedd151]

jwasm is no longer maintained if I am not mistaken. Correction, see _japheth's post below this one. 

If you know already that variable name "name" has some sort of conflict with a reserved name, structure member name, or whatever the issue is, simply use a different variable name than "name". Not rocket science, I would think. Unless there is some need to use "name" as a variable name that I am missing.  ???

[_japheth]

You found a way to fool the assembler - congrats!

You had to use the LABEL directive for that - so IMO it's not really an error, just a somewhat minor incompatibility.

JWasm is still maintained, of course - last update was just a week ago: https://github.com/Baron-von-Riedesel/JWasm

[zedd151]

JWasm is still maintained, of course - last update was just a week ago: https://github.com/Baron-von-Riedesel/JWasm

Hi _japheth. Sorry about that, I did not know. I had thought that it was abandoned in favor of Uasm (I rarely hear anything about jwasm anymore, but hear about Uasm all too often). Thanks for correcting my error. (I have corrected my post above)

[bugthis]

You found a way to fool the assembler - congrats!

Thanks!

You had to use the LABEL directive for that - so IMO it's not really an error, just a somewhat minor incompatibility.

It's a bug. See this thread as a bugreport. I don't have an account at github, thus i can't report bugs there.
JWASM should not allow to use such reserved keywords as variable names in the data section and throw an error or a warning message like MASM does.

By the way, it also works without the LABEL directive as long as you do not use the variable in the code section.

This works too:

Code Select Expand

.model small, C
.stack 128
.data
  name DB "Supercar$"  ; this should not be allowed and throw an error

.code
START:
  MOV AX, @DATA
  MOV DS, AX
  MOV AH, 4Ch
  INT 21h
END START
In this example, MASM also issues a warning message. JWASM issues nothing.
JWASM compiles this without errors or warnings. MASM compiles this, but throws at least a warning message.

The problem with missing error or warning messages is that it could make it difficult to find bugs in code and waste unnecessary time.

JWasm is still maintained, of course - last update was just a week ago: https://github.com/Baron-von-Riedesel/JWasm

You could let the folks at github know so they can add a check in JWASM to see if reserved keywords are used as variable names in the data section.

[bugthis]

....

If you know already that variable name "name" has some sort of conflict with a reserved name, structure member name, or whatever the issue is, simply use a different variable name than "name". Not rocket science, I would think....

I know, but that is not my point.

My point is, that JWASM should throw a warning or error message in first place, if a user tries to use reserved keywords as variable names in the data section.

[bugthis]

Especially this could lead into a nasty and time consuming bug search:

...
2. If you run it, it outputs garbage the label car points to. Because the string "supercar$" isn't
compiled in the code, because name is not a valid variable name.
3. It doesn't output garbage, if you add a valide variable with a string before or after the invalid variable name.
...

Therefore, it is better to have future versions of JWASM throw a warning or error message.

[bugthis]

You found a way to fool the assembler - congrats!
...

I found another bug.

This:

Code Select Expand

.MODEL SMALL, C
.STACK

.DATA
  LIST DB 160 DUP("*")

.CODE
START:
  MOV AX, @DATA
  MOV DS, AX
  MOV [BX], OFFSET LIST ; This line is intentionally wrong

  MOV AH, 4Ch
  INT 21h
END START

MASM will throw an error:

Code Select Expand

CRASH.ASM(11): error A2035: Operand must have size
...                             
  1 Severe Errors  

JWASM will NOT complain and compile the invalid code. If the binary is executed it will result in undefined behavior. Usually the system crashs.
Throwing an error message during compile time would avoid this.

[_japheth]

I found another bug.

[snip]

MASM will throw an error:
CRASH.ASM(11): error A2035: Operand must have size

[snip]

JWASM will NOT complain and compile the invalid code. If the binary is executed it will result in undefined

Actually, the code is correct. LIST is, unlike NAME, not a directive ( the directive is ".LIST" ). What version of Masm throws an error? I tried Masm v6.15, which accepts your source without complains.

The problematic directives are NAME, TITLE, SUBTITLE and SUBTTL, because they accept "anything" as argument - that's true for JWasm and Masm (JWasm more or less just ignores them). However, Jwasm also ignores directive PAGE - this could surely be made more restrictive, because that directive expects one or two numbers as arguments.

Btw, you can use cmdline option -W4 (with JWasm, not Masm) - then the assembler will emit a warning that the directives have been ignored.

[bugthis]

I found another bug.

[snip]

MASM will throw an error:
CRASH.ASM(11): error A2035: Operand must have size

[snip]

JWASM will NOT complain and compile the invalid code. If the binary is executed it will result in undefined

Actually, the code is correct. LIST is, unlike NAME, not a directive ( the directive is ".LIST" ). What version of Masm throws an error? I tried Masm v6.15, which accepts your source without complains.

Reading posts in this forum is probably not a strong point of the forum users, is it?

1. It is ANOTHER and NEW bug. It is not the bug "name problem", but the bug "operand has no size and no error message is thrown".
2. MASM v.5.10 from https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS
3. With JWASM the EXE just hangs the system. MASM 5.10 will not compile and throw an error message.

The problematic directives are NAME, TITLE, SUBTITLE and SUBTTL, because they accept "anything" as argument

Now you are talking about the old bug that was mentioned first in this Thread, not the second new bug.

- that's true for JWasm and Masm (JWasm more or less just ignores them). However, Jwasm also ignores directive PAGE - this could surely be made more restrictive, because that directive expects one or two numbers as arguments.

JWASM should throw a warning when NAME, TITLE, SUBTITLE, SUBTTL or PAGE is used as a name for a variable. I already gave you enough reasons in posting #9 and #7, why this is important. Defending bugs is not a smart approach. JWASM will waste developer's time if this isn't fixed. Fixing means, JWASM has to throw a warning or error message in such cases.

Btw, you can use cmdline option -W4 (with JWasm, not Masm) - then the assembler will emit a warning that the directives have been ignored.

I will test that later. I'm currently sitting in front of a different system that doesn't have JWASM installed.

[_japheth]

Reading posts in this forum is probably not a strong point of the forum users, is it?

This may be true for a few members that tend to be at times in "write-only" mode .

However, I'm not of this kin. As I already wrote, Masm accepts your source without complains - as long as Masm is version 6 or higher. Older versions may indeed emit an error, but this is/was ( obviously? ) a bug in those versions. Anyways, JWasm, as it's mentioned in the docs, is meant to be Masm v6+ compatible.

Now you are talking about the old bug that was mentioned first in this Thread, not the second new bug.

Well, if you are soo pedantic in this regard, you should have opened another thread for your new "bug". Since you didn't, I'm free to answer to both "bug reports" in ONE reply.

JWASM should throw a warning when NAME, TITLE, SUBTITLE, SUBTTL or PAGE is used as a name for a variable

You're probably right. But since Masm v6+ doesn't throw a warning in those cases, JWasm is also quite a bit reluctant in this regard...


1. It is ANOTHER and NEW bug. It is not the bug "name problem", but the bug "operand has no size and no error message is thrown".
2. MASM v.5.10 from https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS
3. With JWASM the EXE just hangs the system. MASM 5.10 will not compile and throw an error message.

The problematic directives are NAME, TITLE, SUBTITLE and SUBTTL, because they accept "anything" as argument

Now you are talking about the old bug that was mentioned first in this Thread, not the second new bug.

- that's true for JWasm and Masm (JWasm more or less just ignores them). However, Jwasm also ignores directive PAGE - this could surely be made more restrictive, because that directive expects one or two numbers as arguments.

JWASM should throw a warning when NAME, TITLE, SUBTITLE, SUBTTL or PAGE is used as a name for a variable. I already gave you enough reasons in posting #9 and #7, why this is important. Defending bugs is not a smart approach. JWASM will waste developer's time if this isn't fixed. Fixing means, JWASM has to throw a warning or error message in such cases.

Btw, you can use cmdline option -W4 (with JWasm, not Masm) - then the assembler will emit a warning that the directives have been ignored.

I will test that later. I'm currently sitting in front of a different system that doesn't have JWASM installed.
[/quote]