View Issue Details

IDProjectCategoryView StatusLast Update
0006123unrealircdpublic2022-06-05 08:22
Reporterwestor Assigned Tosyzop  
Status resolvedResolutionfixed 
Product Version6.0.4-rc2 
Fixed in Version6.0.4 
Summary0006123: buildvarstring() function miss-behaving in some cases

i've found a bug under buildvarstring() function that will fail or miss-behaving in some cases.

1. When for example in blacklist module on reason you specify $serv instead of $server it still evaluates, this shouldn't happen because $serv doesn't exists.
2. I don't know if this is by design but might break modules, like if under module is set to use $test and someone use $TeSt in config it's still evaluates, maybe here needs to be case-sensitive checkup ?
3. Also i don't know what will happen if a module try to use UPPER-case to build, my guess here is that is going to break @define items.

Suggestion is, allow modules use only lower-case + case-sensitive variable names to build under that function, by this everyone will be happy and nothing can break :P

- Thanks!
Steps To Reproduce1. Load blacklist module
2. Set a blacklist block and enter in reason $serv instead of $server
3. Check that $serv is still evaluates when triggers


1. Load blacklist module
2. Set a blacklist block and enter in reason $SeRV or $SeRveR
3. Check that $SeRV and $SeRveR are both evaluating
TagsNo tags attached.
3rd party modules



2022-06-05 08:20

administrator   ~0022549

Last edited: 2022-06-05 08:22

Had to see it to understand the issue. Fixed now, thanks :).
As for case-sensitivity, i usually prefer case-sensitive too but i don't think it's much of an issue in this case. There is something to say about both cases, though.

commit 28d3875aa9d8b447905ae90c6ee7a7e32f575d76 (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD)
Author: Bram Matthys <>
Date: Sun Jun 5 08:15:00 2022 +0200

    Make variables in set::reject-message and other buildvarstring() usage
    no longer expand shorter versions of a variable. It previously had some
    unintended form of magic autocomplete where $serv was handled the same
    way as if it was $server. This could cause issues in the long run when
    variables are added and the meaning of the short form changes.
    Reported by westor in

Issue History

Date Modified Username Field Change
2022-06-05 01:14 westor New Issue
2022-06-05 08:06 syzop Priority high => normal
2022-06-05 08:20 syzop Assigned To => syzop
2022-06-05 08:20 syzop Status new => resolved
2022-06-05 08:20 syzop Resolution open => fixed
2022-06-05 08:20 syzop Fixed in Version => 6.0.4
2022-06-05 08:20 syzop Note Added: 0022549
2022-06-05 08:21 syzop Note Edited: 0022549
2022-06-05 08:22 syzop Note Edited: 0022549