In the old version of glibc and O2 is enabled, replacing the strncmp argument with a macro will cause the compilation to fail

[hardboydu]

Problem

neovim-nightly/src/nvim/autocmd.c:1248:43: error: macro "strncmp" requires 3 arguments, but only 2 given
 1248 |   if (strncmp(*argp, S_LEN("<nomodeline>")) == 0) {
      |                                           ^
In file included from /usr/include/string.h:633,
                 from neovim-nightly/src/nvim/autocmd.c:8:
/usr/include/bits/string2.h:919: note: macro "strncmp" defined here
  919 | # define strncmp(s1, s2, n)                                                   \
      |
neovim-nightly/src/nvim/autocmd.c:2362:54: error: macro "strncmp" requires 3 arguments, but only 2 given
 2362 |   return patlen >= 8 && strncmp(pat, S_LEN("<buffer")) == 0 && (pat)[patlen - 1] == '>';
      |                                                      ^
/usr/include/bits/string2.h:919: note: macro "strncmp" defined here
  919 | # define strncmp(s1, s2, n)                                                   \
      |
make[2]: *** [src/nvim/auto/autocmd.c.generated.h] Error 1

Steps to reproduce

cmake ../neovim-nightly \
		-DCMAKE_INSTALL_PREFIX=/opt/neovim \
		-DCMAKE_BUILD_TYPE=Release

Expected behavior

Compilation succeeded

Neovim version (nvim -v)

commit 66a1e02

Vim (not Nvim) behaves the same?

N/A

Operating system/version

CentOS 7.9

Terminal name/version

windows terminal

$TERM environment variable

xterm-256color

Installation

build from repo

[moonstruckmoth]

I'm facing the same issue and I've tracked down the commit from where it started failing to compile.

The commit is as below

commit c37695a (HEAD)
Author: James 89495599+IAKOBVS@users.noreply.github.com
Date: Tue Jun 11 22:40:24 2024 +0700

refactor: use S_LEN(s) instead of s, n (#29219)

[dundargoc]

@IAKOBVS

[IAKOBVS]

@IAKOBVS

S_LEN macro doesn't work when passed as an argument to another macro. That's why I didn't use it for the STRNICMP macros, only functions.

[clason]

Yes, obviously. Can you fix this so it works on all supported platforms, or should we revert that commit?

[IAKOBVS]

Yes, obviously. Can you fix this so it works on all supported platforms, or should we revert that commit?

Just revert it.

[gpanders]

Is this something we can test for in CI? Otherwise how we will know if any use of S_LEN is safe? (Unless we make a rule: "never use S_LEN in stdlib functions because those could secretly be macros").

[clason]

Not without containers. (But I believe this sort of "macro wrappers for gcc" in glibc can be researched; It will take some effort, though.)

[dundargoc]

Is this something we can test for in CI? Otherwise how we will know if any use of S_LEN is safe? (Unless we make a rule: "never use S_LEN in stdlib functions because those could secretly be macros").

I don't see how we could. Even if we start testing centos specifically it won't account for other distros. We could start testing a slew of popular distros (centos, debian, fedora, arch, manjaro, etc etc) but that is going to be expensive CI-wise.