Is there a chance that this can be fixed, to comply with recent C standards?

No, probably not.

1. SQLite is used by countless systems, many of which use older compilers. Changing SQLite to appease the "recent standards" would cause untold and needless pain for many users.

2. It's a lot of work that serves no useful propose. ("Standards compliant" is not a useful purpose. "Usefulness" is a useful propose.)

3. There are no real errors discovered by -fsanitize=strict-bounds, only faux-errors; constructs that strict-bounds does not understand. On the other hand, making changes to appease strict-bounds has a high risk of introducing new, actual errors. So changes like this would end up increasing the number of errors in the code, not decreasing them.

This is how Tcl handles this:

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) # define TCLFLEXARRAY #elif defined(__GNUC__) && (__GNUC__ > 2) # define TCLFLEXARRAY 0 #else # define TCLFLEXARRAY 1 #endif

That is certainly a useful start. However, recognize that we also have to redo many sizeof() computations, depending on the value of TCLFLEXARRAY.

Instead of sizeof(...), use offsetof(..., lastfieldname)

Note that you have to use offsetof even in C99. For example, these two structs have the same size because of alignment padding:

typedef struct buf1 {
    size_t size;
    unsigned short flags;
    unsigned char data[1];
} buf1;

typedef struct buf0 {
    size_t size;
    unsigned short flags;
    unsigned char data[];
} buf0;

The real solution is to make -fsanitize=strict-bounds treat a 1-element array at the end of a struct as having dynamic size. File bugs against any and all compilers! :-)

The real solution is to make -fsanitize=strict-bounds treat a 1-element array at the end of a struct as having dynamic size.

Yeah, verily!

Nevertheless, my experience is that the standards people hate the C programming language and will do everything they can to destroy it by standardizing nonsense, so I don't think such a proposal will gain much traction. Hence, I'm working now to implement changes along the lines of what Jan suggested.

These "enhancements" would certainly lead to a huge number of memory errors, where it not for our excellent test suite....

Check-in 20250315195519 and following make use of the C99 flexible array feature, on systems that support that, using techniques outlined earlier in this thread. No warnings given with -fsanitize=bounds-strict, at least not when we use that option here.

Thank you, this is wonderful! Looking forward to adding this to the RSQLite R package when released.

Please consider adding the package, or at least testing it, using the latest trunk code, which is well tested, as the next official release will likely be months and months away.

Thanks. Added sqlite.c and sqlite.h for the latest trunk from the tarball, verified it contains the new FLEXARRAY code: https://github.com/r-dbi/RSQLite/commit/306da515dff62a1aee979fb68e72cf265173cb3a#diff-3130402057210a5a9cb567610268ca9d5a732ca340f7d2815b197c5804020186R15185

Current failing run: https://github.com/r-dbi/RSQLite/actions/runs/13558248111/job/37896668104#step:6:11467

Now running, let's see: https://github.com/r-dbi/RSQLite/actions/runs/13891506386/job/38864200763#step:3:73

I don't know how to operator your CI system. Can you give me an error message of some kind to work with?

No error message, the check that failed previously is now successful. 🎉