CLANG 18 - base64.cpp: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]

[micfogas]

Compiling lsmcd on AlmaLinux 9. I received an error on base64.cpp during compile as follows, though the error also occurs in several other files, depending how many parallel processes are used:
base64.cpp:36:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
36 | register const char *pEncoded = encoded;
| ^~~~~~~~
base64.cpp:37:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
37 | register unsigned char e1, prev_e = 0;
| ^~~~~~~~
base64.cpp:37:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
37 | register unsigned char e1, prev_e = 0;
| ^~~~~~~~
base64.cpp:38:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
38 | register char phase = 0;
| ^~~~~~~~
base64.cpp:39:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
39 | register unsigned char *pDecoded = (unsigned char *)decoded;
| ^~~~~~~~
base64.cpp:40:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
40 | register const char *pEnd = encoded + size ;
| ^~~~~~~~
base64.cpp:44:9: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
44 | register int ch = *pEncoded++;
| ^~~~~~~~
base64.cpp:75:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
75 | register const unsigned char *pDecoded = (const unsigned char *)decoded;
| ^~~~~~~~
base64.cpp:76:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
76 | register constmv -f .deps/autobuf.Tpo .deps/autobuf.Po unsigned char *pEnd = (const unsigned char *)decoded + size
| ^~~~~~~~
base64.cpp:78:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
clang -DHAVE_CONFIG_H -I. -I../../src -I../../include -I../../src -I/usr/include -g -O2 -fstack-protector -MT blockbuf.o -MD -MP -MF .deps/blockbuf.Tpo -c -o blockbuf.o blockbuf.cpp
78 | register char *pEncoded = encoded;
| ^~~~~~~~
base64.cpp:79:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
79 | register unsigned char ch;
| ^~~~~~~~
11 errors generated.
make[4]: *** [Makefile:600: base64.o] Error 1

My configure command is:
CC="clang" CXX="clang" "LDFLAGS=" -fuse-ld=lld" CFLAGS=" -O2" ./configure --prefix=/usr/local/lsmcd

EL9 comes pre-installed with gcc 11:
gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-2)

The packaged clang on EL9 is clang 18:
clang version 18.1.8 (AlmaLinux OS Foundation 18.1.8-3.el9)

I have attached my config.log file.
config.log

---

register pointers are only warnings in gcc, but fatal errors in clang.

Adding CXXFLAGS="-Wno-register" on the configure command line will allow clang to complete the compile without the errors, and will skip the warnings in gcc.

However, the solution for ISO C++ 17 should be to rename register to REGISTER, or avoid the register keyword all together.

gcc has used ISO C++ 17 since gcc 8. These warnings are being thrown for any modern compilers. Hopefully an update will rename register if ISO C++ 17 is detected.

[rperper]

We recommend that you not use configure. Use:

cmake .
make
sudo make install

We're recommending new customers use redis when possible and we have much more complete Redis support for cPanel and Plesk for the LSCWP plugin.
Thanks,

Bob

[micfogas]

Thanks for the quick reply, Bob. I'll recompile with that, since it's recommended.

I'll share the official story regarding the deprecation of the register keyword:
The register keyword was deprecated in the 2011 C++ standard. C++17 tries to clear the standard, so the keyword is now removed. This keyword is reserved now and might be repurposed in future revisions.

Using cmake to generate the file will still produce the warnings, though, since the generated Makefile is still using the system's compiler suite, right?

---

Anyway, I am using redis and phpredis with igbinary for serialization, cache, and sessions (best combo I've found). In fact memcached is a bit too finicky. I can compile it separately from PHP 8.4 (using phpize, configure, and make) or as a static module (placing memcached in ext/ and rerunning buildconf, then adding --enable-memcached=static on the php configure line), but as a shared module (--enable-memcached=shared on the php configure line) it throws quite a few errors. I wanted to test memcached with lsmcd against redis, with both using igbinary, for some performance metrics. It's the only reason I was bothering with it.

Usman still offers memcached and lsmcd in CyberPanel. I'm hoping to get with him to redo the source tree to modernize it into a docker overlay that sits on top of lsws/ols as a privileged container. But that's out of the scope of this ticket.

Regarding control panels, unfortunately most of them are aimed at resellers, and there really aren't any middle ground control panels to extend functionality of lsws's admin control panels that simplify things like caching, owasp rules, letsencrypt, and even crowdsec integration, or control panels that target single tenants. I'm not a fan of plesk or cpanel. I don't like places all sites as subdirectories in /var/www/html and relying on .htaccess and rewrites to prevent them all from being accessible paths in the primary site. But again, I'm way out of scope of this ticket here.

Have you guys considered archiving lsmcd? Existing users, or those unable to use redis, would still be able to pull and compile it. But archive status often deters people who don't have a specific reason and aren't existing users. A slimmed down modified redis server could be made as a replacement, as an lsws module, would be able to integrate and avoid the need for opening a localhost port or even socket, for overly restrictive webhosts. It would be more reliable that separate redis or lsmcd, and faster. A companion php module would simplify communication to it by acting as a redis module on the php exposed side, then establishing connection to lsdis (customized redis for lsws), taking care of the transport and handing the data directly to the cache server.

Enough rambling. Thanks for the reply, I might throw these ideas on the lsws forums.

[rperper]

Fair enough points about the control panels we've added support to. I hope CyberPanel gets back with the program and adds Redis support. In particular, I'd love to see it add our LiteSpeed Containers functionality to it (see https://blog.litespeedtech.com/2024/09/09/introducing-litespeed-containers/) It would take some work, but the core of LiteSpeed Containers (cgroups and namespace support) is in OLS.

Also a good thought about archiving LSMCD. We'll be moving in that direction.

Thanks for your excellent thoughts and experiences!

Bob