Build problem smatch 1.75

Build problem smatch 1.75

[Harshit Mogalapalli]

Hi Dan,

Build error:

pre-process.c: In function ‘parse_expansion’:
pre-process.c:1648:16: error: variable-sized object may not be initialized
  1648 |         struct arg_state args[slots] = {};
       |                ^~~~~~~~~
pre-process.c: In function ‘find_include’:
pre-process.c:1015:56: warning: ‘%s’ directive output may be truncated 
writing up to 255 bytes into a region of size between 1 and 4096 
[-Wformat-truncation=]
  1015 |                         snprintf(buf, sizeof(buf), "%s/%s", 
cwd, entry->d_name);
       |                                                        ^~
pre-process.c:1015:25: note: ‘snprintf’ output between 2 and 4352 bytes 
into a destination of size 4097
  1015 |                         snprintf(buf, sizeof(buf), "%s/%s", 
cwd, entry->d_name);
       | 
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


I think the problem is introduced by:

Fixes: 1a9a98e3c7b8 ("__VA_OPT__: parsing")

I think we need a memset() in parse_expansion()

thanks,
Harshit

Re: Build problem smatch 1.75

[Dan Carpenter]

On Mon, May 04, 2026 at 01:25:43PM +0530, Harshit Mogalapalli wrote:
> Hi Dan,
> 
> Build error:
> 
> pre-process.c: In function ‘parse_expansion’:
> pre-process.c:1648:16: error: variable-sized object may not be initialized
>  1648 |         struct arg_state args[slots] = {};
>       |                ^~~~~~~~~

What compiler are you using?  This is a bug in Sparse.  We should
probably fix it there.

Apparently you can't use variable length arrays with an initializer.
Why do C compilers have to suck?  They should have made an exception for
memset to zero.

> pre-process.c: In function ‘find_include’:
> pre-process.c:1015:56: warning: ‘%s’ directive output may be truncated
> writing up to 255 bytes into a region of size between 1 and 4096
> [-Wformat-truncation=]
>  1015 |                         snprintf(buf, sizeof(buf), "%s/%s", cwd,
> entry->d_name);
>       |                                                        ^~
> pre-process.c:1015:25: note: ‘snprintf’ output between 2 and 4352 bytes into
> a destination of size 4097
>  1015 |                         snprintf(buf, sizeof(buf), "%s/%s", cwd,
> entry->d_name);
>       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> I think the problem is introduced by:
> 
> Fixes: 1a9a98e3c7b8 ("__VA_OPT__: parsing")
> 
> I think we need a memset() in parse_expansion()

The snprintf() warnings are my fault but I hate that warning.  I don't
care if the snprintf() truncates...  Truncating is the whole reason that
I use it...  Anyway, sure let me silence that.

regards,
dan carpenter

From bcc58b9ccf06d28ab6be4f0992bc74f462aa12f8 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <error27@gmail.com>
Date: Mon, 4 May 2026 11:16:24 +0300
Subject: [PATCH] pre-process: silence a -Wformat-truncation warning

Add a check for snprintf() overflows to make GCC happy.

Signed-off-by: Dan Carpenter <error27@gmail.com>
---
 pre-process.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/pre-process.c b/pre-process.c
index d9a0a9e73a73..fdcc29338c94 100644
--- a/pre-process.c
+++ b/pre-process.c
@@ -1012,7 +1012,11 @@ const char *find_include(const char *skip, const char *look_for)
 		lstat(entry->d_name, &statbuf);
 
 		if (strcmp(entry->d_name, look_for) == 0) {
-			snprintf(buf, sizeof(buf), "%s/%s", cwd, entry->d_name);
+			int cnt;
+
+			cnt = snprintf(buf, sizeof(buf), "%s/%s", cwd, entry->d_name);
+			if (cnt >= sizeof(buf))
+				return NULL;
 			closedir(dp);
 			return buf;
 		}
-- 
2.53.0

Re: Build problem smatch 1.75

[Harshit Mogalapalli]

On 04/05/26 13:50, Dan Carpenter wrote:
> On Mon, May 04, 2026 at 01:25:43PM +0530, Harshit Mogalapalli wrote:
>> Hi Dan,
>>
>> Build error:
>>
>> pre-process.c: In function ‘parse_expansion’:
>> pre-process.c:1648:16: error: variable-sized object may not be initialized
>>   1648 |         struct arg_state args[slots] = {};
>>        |                ^~~~~~~~~
> 
> What compiler are you using?  This is a bug in Sparse.  We should
> probably fix it there.
> 

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-host-pie 
--enable-host-bind-now --enable-languages=c,c++,fortran,lto 
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
--enable-threads=posix --enable-checking=release --enable-multilib 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-gcc-major-version-only --with-linker-hash-style=gnu 
--enable-plugin --enable-initfini-array --without-isl 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-gnu-indirect-function --enable-cet --with-tune=generic 
--with-arch_64=x86-64-v2 --with-arch_32=x86-64 
--build=x86_64-redhat-linux --with-build-config=bootstrap-lto 
--enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.1 20220421 (Red Hat 11.3.1-2.1.0.2) (GCC)



> Apparently you can't use variable length arrays with an initializer.
> Why do C compilers have to suck?  They should have made an exception for
> memset to zero.
> 
>> pre-process.c: In function ‘find_include’:
>> pre-process.c:1015:56: warning: ‘%s’ directive output may be truncated
>> writing up to 255 bytes into a region of size between 1 and 4096
>> [-Wformat-truncation=]
>>   1015 |                         snprintf(buf, sizeof(buf), "%s/%s", cwd,
>> entry->d_name);
>>        |                                                        ^~
>> pre-process.c:1015:25: note: ‘snprintf’ output between 2 and 4352 bytes into
>> a destination of size 4097
>>   1015 |                         snprintf(buf, sizeof(buf), "%s/%s", cwd,
>> entry->d_name);
>>        | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> I think the problem is introduced by:
>>
>> Fixes: 1a9a98e3c7b8 ("__VA_OPT__: parsing")
>>
>> I think we need a memset() in parse_expansion()
> 
> The snprintf() warnings are my fault but I hate that warning.  I don't
> care if the snprintf() truncates...  Truncating is the whole reason that
> I use it...  Anyway, sure let me silence that.
> 
> regards,
> dan carpenter
> 
>  From bcc58b9ccf06d28ab6be4f0992bc74f462aa12f8 Mon Sep 17 00:00:00 2001
> From: Dan Carpenter <error27@gmail.com>
> Date: Mon, 4 May 2026 11:16:24 +0300
> Subject: [PATCH] pre-process: silence a -Wformat-truncation warning
> 
> Add a check for snprintf() overflows to make GCC happy.
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
>   pre-process.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/pre-process.c b/pre-process.c
> index d9a0a9e73a73..fdcc29338c94 100644
> --- a/pre-process.c
> +++ b/pre-process.c
> @@ -1012,7 +1012,11 @@ const char *find_include(const char *skip, const char *look_for)
>   		lstat(entry->d_name, &statbuf);
>   
>   		if (strcmp(entry->d_name, look_for) == 0) {
> -			snprintf(buf, sizeof(buf), "%s/%s", cwd, entry->d_name);
> +			int cnt;
> +
> +			cnt = snprintf(buf, sizeof(buf), "%s/%s", cwd, entry->d_name);
> +			if (cnt >= sizeof(buf))
> +				return NULL;
>   			closedir(dp);
>   			return buf;
>   		}

This works for silencing snprintf warning.

Thanks for the fix.

Regards,
Harshit

Re: Build problem smatch 1.75

[Dan Carpenter]

On Mon, May 04, 2026 at 04:17:51PM +0530, Harshit Mogalapalli wrote:
> On 04/05/26 13:50, Dan Carpenter wrote:
> > On Mon, May 04, 2026 at 01:25:43PM +0530, Harshit Mogalapalli wrote:
> > > Hi Dan,
> > > 
> > > Build error:
> > > 
> > > pre-process.c: In function ‘parse_expansion’:
> > > pre-process.c:1648:16: error: variable-sized object may not be initialized
> > >   1648 |         struct arg_state args[slots] = {};
> > >        |                ^~~~~~~~~
> > 
> > What compiler are you using?  This is a bug in Sparse.  We should
> > probably fix it there.
> > 
> 

I reported this to the Sparse devs, but for now I just changed this to a
memset() to fix the build in Smatch.

regards,
dan carpenter

Re: Build problem smatch 1.75

[Harshit Mogalapalli]

On 05/05/26 16:11, Dan Carpenter wrote:
>>> What compiler are you using?  This is a bug in Sparse.  We should
>>> probably fix it there.
>>>
> I reported this to the Sparse devs, but for now I just changed this to a
> memset() to fix the build in Smatch.

Thanks a lot Dan.

Regards,
Harshit