On Tue, 2026-02-17 at 12:24 -0500, David Malcolm wrote:
> On Tue, 2026-02-17 at 16:33 +0000, Qing Zhao wrote:
> > Hi, David,
> >
> > I am working on PR96503 right now, and the initial implementation
> > has
> > some regression in analyzer as show from the following small
> > testing
> > case:
> > $ cat t.c
> > #include <stdlib.h>
> > #include <stdio.h>
> > #include <stdint.h>
> >
> > /* Tests with constant buffer sizes. */
> >
> > void test_2 (void)
> > {
> > int32_t *ptr = (int32_t *) malloc (21 * sizeof (int16_t)); /* {
> > dg-
> > line malloc2 } */
> > free (ptr);
> >
> > /* { dg-warning "allocated buffer size is not a multiple of the
> > pointee's size \\\[CWE-131\\\]" "warning" { target *-*-* } malloc2
> > }
> > */
> > /* { dg-message "42 bytes" "note" { target *-*-* } malloc2 } */
> > /* { dg-message "'int32_t \\*' (\\\{aka '(long )?int \\*'\\\})?
> > here; 'sizeof \\(int32_t (\\\{aka (long )?int\\\})?\\)' is '4'"
> > "note" { target c } malloc2 } */
> > /* { dg-message "'int32_t\\*' (\\\{aka '(long )?int\\*'\\\})?
> > here;
> > 'sizeof \\(int32_t (\\\{aka (long )?int\\\})?\\)' is '4'" "note" {
> > target c++ } malloc2 } */
> > }
> >
> > ****Without my change, the IR for the above is:
> >
> > void test_2 ()
> > {
> > int32_t * ptr;
> >
> > ptr = malloc (42);
> > free (ptr);
> > }
> >
> > And when compiled with "-fdiagnostics-plain-output -fanalyzer -
> > Wanalyzer-too-complex -Wanalyzer-symbol-too-complex -S”:t.c: In
> > function ‘test_2’:
> > t.c:9:30: warning: allocated buffer size is not a multiple of the
> > pointee's size [CWE-131] [-Wanalyzer-allocation-size]
> > t.c:9:30: note: (1) allocated 42 bytes here
> > t.c:9:30: note: (2) assigned to ‘int32_t *’ {aka ‘int *’} here;
> > ‘sizeof (int32_t {aka int})’ is ‘4’
> >
> > **** with my change, the IR for the above is:
> > void test_2 ()
> > {
> > int32_t * ptr;
> >
> > _1 = malloc (42);
> > ptr = .ACCESS_WITH_SIZE (_1, 42, 4B, 1);
> > free (ptr);
> > }
> >
> > And the analyzer cannot detect the warning anymore.
> >
> > *****After studying a little bit in analyzer, I realize that I
> > might
> > need to add the IFN_ACCESS_WITH_SIZE as a known internal function
> > into
> > Analyzer, (similar as malloc), such as:
> >
> > kfm.add ("malloc", std::make_unique<kf_malloc> ());
> >
> > Is this correct understanding?
>
> Yes, though IFNs use a slightly different subclass and registration
> mechanism - see register_known_functions in analyzer/kf.cc, which
> currently has:
>
> /* Internal fns the analyzer has known_functions for. */
> {
> kfm.add (IFN_BUILTIN_EXPECT, std::make_unique<kf_expect> ());
> }
>
> You'll want to add something similar for IFN_ACCESS_WITH_SIZE.
>
> > I also need to define a “kf_access_with_size” class similar as
> > “kf_malloc” and define the kf_access_with_size::impl_call_pre as
> > well?
>
> Yes. Looks like you'll want to use:
> model->deref_value
> to get at the region pointed to by the pointer, and
> model->get_manager ()->get_sized_region ()
> to get a region of the correct size for the access at that address.
>
> Normally we'd use model->get_store_value (region) to actually do the
> access and get the contents of memory, which should do the bounds
> checking for you. So the simplest approach is probably to do that
> and
> discard the result, or perhaps for efficiency you could just call
> check_region_for_read on it (but that might miss some special-cases
> e.g. when the region is zero-sized).
Or if this just a no-op pass through of the param 1, then the behavior
of kf_expect might be appropriate.
>
> Dave
>
> >
> > What else I need to do in analyzer to resolve this problem?
> >
> > Thanks a lot for your help.
> >
> > Qing
> >
>
