There is at least one class of really bad behavior nsis allows by default: usage of undefined defines. This results in the sentinel happily being part of strings despite not being available. In most cases, this is incorrect behavior (due to misconfiguration) or missing escapes in strings where they should be escaped.
This is completely unacceptable behavior for production software and currently requires checking stdout of nsis looking for this kind of problem. This results in unnecessary build time (it should fail on first undefined usage of the definition).
There should be a flag, e.g. -error-on-warnings that will treat all warnings as errors and exit with an error code.
Also, real classy using "-XOutfile poop.exe" in the help message guys, way to keep it professional.
I don't know why the compiler was designed to allow ${undefined} to be parsed without warnings. I know batch files work this way but that does not make it right.
The compiler does the wrong thing when faced with "$${somedefine}" while "$$0" is escaped correctly (This can be fixed by defining NSIS_FIX_DEFINES_IN_STRINGS when compiling MakeNSIS). I don't know if we will break things if we fix $${x} or allow $\$ to escape $. If we are going to warn it would be nice to have a real way to escape (Not counting the "${DOLLAR}{undefined}" hack or ${U+24}{undefined}).
I fixed XOutfile last year IIRC.
Last edit: Anders 2014-07-11
The next release will support -WX to treat warnings as errors...
Last edit: Anders 2017-06-19