Lua is even worse.

Sadly, javascript is exactly the same. If you don't use var, let, or const, the variable is global.

Sometimes even a compiler won't follow the language's rules.

MSVC 6 ignored the rules of scoping for blocks, a variable instantiated within a for loop block was visible in code that followed the for block.

That bit my tuchas more than once until I went to another compiler.

I was being sarcastic!

LMAO didn't notice. The VESC creator could have chosen really any language, but chose Lisp.

MSVC 6 ignored the rules

MS back then was notorious for having their own 'enhancements'. They still do to some extent so that windows.h et al will still compile. Try setting Disable Language Extensions to True!

I have yet to have a problem with strict ISO C/C++ code when disabling language extensions in VS, not that there won't ever be one. I never have had a problem before. The default for VS is to not disable language extensions.

Setting the project's warning level to level 4 (the default is level 3) with WinAPI code and watch the diagnostic output window get all clogged up with lots of trivial BS warnings. Strict ISO C/C++ code won't do that.

Setting the warning level to /Wall no matter what the project, C/C++ or WinAPI, is a shit storm of IMO really bogus and trivial warnings. BS about C++ stdlib functions inlined or not inlined and so on.

Unless I have reasons to change the extensions or warning level settings I generally leave them at the default.

I did modify a while back the defaults so the C++ standard for new projects is set to std:c++latest. At the time a new project/solution defaults to ISO C++14. Only recently did VS add ISO C++20 as an option. It was ISO C++14 (default), ISO C++17 or Preview - Features from the Latest C++ Working Draft (/std:c++latest).

Working with modules used to require enabling the experimental C++ standard libraries setting. Now that is no longer required. C++20 or C++23 modules.

Setting the warning level to /Wall no matter what the project, C/C++ or WinAPI, is a shit storm of IMO really bogus and trivial warnings. BS about C++ stdlib functions inlined or not inlined and so on.

I know. I reported this to MS quite a while ago but they're not interested as long as their code compiles with no warnings at level 4 (the recommended level).

GCC had up to version 8:

-ffor-scope -fno-for-scope If -ffor-scope is specified, the scope of variables declared in a for-init-statement is limited to the for loop itself, as specified by the C++ standard. If -fno-for-scope is specified, the scope of variables declared in a for-init-statement extends to the end of the enclosing scope, as was the case in old versions of G++, and other (traditional) implementations of C++.

And the version 8 had also note:

This option is deprecated and the associated non-standard functionality will be removed.

---

Perl has global and my scoped variables. I have not knowingly used Perl before this Summer. Lucky me.

MSVC 6 ignored the rules of scoping for blocks, a variable instantiated within a for loop block was visible in code that followed the for block.

That was before the 1998 standardization. C++ compilers before the turn of the century were uniformly terrible.

Both GCC and MSVC had it possible to compile pre-standard code years after 1998. The difference was that in MSVC the "enhancements" were the default, while in GCC you had to explicitly request '-ffor-scope'. Then again, GCC defaults to "GNU dialect" even today, not to strict standard.

If we're honest the standard is really just aspirational. Compiler developers just do WTF they want. They're even worse on weird platforms, with basic standard library features missing. Ages ago I was writing an Android native app and it was the weirdest things that weren't implemented for GCC (even though Clang did have them). Most bizarrely, it had std::shared_ptr but not std::unique_ptr.

Following this thread like a soap-opera, except no one’s best friend has died yet and no one is secretly pregnant by their second cousin’s fiancé.

Following this thread like a soap-opera

Heh™. This behavior here is somehow different than what happens in other long-lasting threads? Hardly.

The original intent of this thread was addressed the first couple of replies. This was more of a bitchin' and whingin' thread from the get-go than anything else.

And the usual morphin' and mutatin' happened and continues.

Just out of curiosity, I googled 'forum spambots that edit post with spam' and as expected, this is a problem on a lot of fora:
https://forums.blurbusters.com/viewtopic.php?t=3706
https://meta.discourse.org/t/spam-bots-tricking-discourse-filter-by-editing/101684/5
https://xenforo.com/community/threads/newish-type-of-spam-im-seeing.219053/
https://www.reddit.com/r/SEO/comments/l0dqo9/how_can_i_stop_forum_spam_bots/

There are high-cost and low-cost solutions that also range in user-friendliness.

I think, for this website, it'd be easy enough to do some or all of the following to stifle out spammers (be they bots or human):
- Posters with less than X posts can only edit their post within a narrow time window (e.g. an hour)
- Posters with less than X posts cannot have anything in their bios except their username (or maybe we just disallow hyperlinks in the bio?)
- If you don't make a post within X days of registering, you have to re-verify your email address before posting.

That won't stop spammers from copypasting reddit threads, but would at least prevent them from secretly sneaking in spam links.

Even without those measures in place, having a small, trusted moderation team could mitigate most issues.

Quoth the Grey Wolf:

All the best threads unravel to reveal something else.

having a small, trusted moderation team could mitigate most issues

Definitely! I'm amazed that the owner hasn't done this as it would relieve the owner from most if not all of any admin - especially if they could validate new users. This is what other forum sites do.

**Boot!**