Repeated string equate causes an infinite loop when referenced

[yenatch]

string equs "anything"
string equs "anything"
string

rgbasm will accept the following without complaint if string is not referenced:

string equs "anything"
string equs "anything"

If the equates don't match, rgbasm will raise Buffer safety margin exceeded:

string equs "anything"
string equs "anything else"

[yenatch]

Oops, this is not really a bug (except for the circular reference causing an infinite).

[AntonioND]

It took me a while to understand the problem.

string equs "anything"
string equs "anything"

That is converted to:

string equs "anything"
anything equs "anything"

If string is used, it will be replaced by anything, which will be replaced by anything again, and so on. That's why the bug only happens when you actually use string. The third case is the same thing, I guess that the line yyunputstr(s = sym_GetStringValue(dest)) is executed in an infinite loop causing the buffer to be filled (and that's why that error message is showing).

I don't think that a circular reference should be prohibited, it could be useful for recursive expansion of EQUS, so I don't know what to do.

[AntonioND]

Maybe a warning? Something like "Self reference in an EQUS, it may cause an infinite loop." that is only shown once per execution of rbgasm.

Not sure about how to detect it, though. It's not just a symbol referencing itself, it could be a chain.

[BenHetherington]

Hmm... I'm struggling to think of any reasons why someone would deliberately use EQUS recursively. As a result, I'd say we should show an error and stop straightaway, to avoid a (most likely undesired) infinite loop.

As for detecting it, we could keep track of all the EQUSes we've used in the current evaluation (e.g. with a stack), and stop if we encounter an EQUS we've already seen. This could be a faff, but it'd solve the issue (unless if I've overlooked something).

[AntonioND]

Well, an EQUS can be assigned a multiline string. You can do something like:

STORE_ARGS EQUS "IF _NARG > 0\n DB \\1\n SHIFT\n STORE_ARGS\nENDC"

And you could use it to store an arbitrary number of macro arguments. You can't do that with a macro inside a macro.

EDIT: No, that wouldn't work, sorry. But that's the idea, you could maybe use them to define things. I'm not too sure about limiting things just because we can't find an use case now.

[AntonioND]

On the other hand, it is true that some of the most hacky constructs in C are done using #define, so prohibiting recursive EQUS could make sense. I'm not sure about this.

Relevant: http://stackoverflow.com/a/12447739

[AntonioND]

By the way, the same problem exists with macros:

HELLO : MACRO
    HELLO
ENDM

    HELLO

And this is a completely legitimate use-case of macros, so I'm really not sure about this.

[AntonioND]

I think that the only thing that can realistically be done is to warn about this problem.

I don't think there's a good way of solving this. Both EQUS and macros can have this problem, and it can be hidden very easily if the coder wants to (by having a chain of 2 or 3 definitions, for example).

It cannot be detected by the parser either because when it finds a symbol that has to be replaced by an EQUS it simply sends the string to the lexer for it to handle. It cannot even be detected by preventing the replacement of the same EQUS in the same line twice, you could be trying to use it in two different places and that's not a problem.

Also, it can only be detected when it is actually used: An EQUS may change if you redefine it.

Macros are even worse. If you hide the recursive usage of the macro inside an IF, how can you even know if the problem is going to happen or not? You could even do crazy things like getting the assembler into a loop that only ends when a specific time is reached! xD

EDIT: Actually, that last part isn't true, the time is only calculated when the assembler starts.

[AntonioND]

I've pushed this: 4228e3e

I really don't know if it makes sense to spend time trying to detect this considering that any possible test is going to be incomplete and, in the end, everything comes down to the programmer doing things right..

[meithecatte]

I would say to not expand macros nor equs when used as a macro or equ name

[AntonioND]

I don't think I understand what you mean, could you show what you mean with an example?

[meithecatte]

When defining an EQU, the part on the left of it should not be fed into the macro expanding part. That way, string equs "anything" string equs "anything" will stay that way and just redefine string. Same goes for macros - you probably won't need any macros or similar in the name part.

[AntonioND]

That doesn't help solve the problem. You can still do this:

AAA EQUS "BBB"
BBB EQUS "AAA"

AAA ; Infinite loop

[ISSOtm]

A possible solution would be to enforce a recursion depth limit. This limit could be passed as a command-line argument, too, so a recursion-heavy program could be still made working.

[ISSOtm]

Fixed in e0e8170