Thread

1. BUG #18848: DEREF_AFTER_NULL.EX.COND After having been compared to a NULL

   PG Bug reporting form <noreply@postgresql.org> — 2025-03-14T09:12:41Z

   The following bug has been logged on the website:
   
   Bug reference:      18848
   Logged by:          Nikita
   Email address:      pm91.arapov@gmail.com
   PostgreSQL version: 16.6
   Operating system:   ubuntu 20.04
   Description:        
   
   Looks like there is inconsistency with 'ind_name' and 'int_type' checks. In
   one place both are checked. In other place only the second one is checked.
   It's possible that when the second is not NULL the first is also not NULL.
   If this is so then the problem is not real. But it's hard to prove this. In
   any case the code needs to be made more clear.
   
   diff --git a/src/interfaces/ecpg/preproc/type.c
   b/src/interfaces/ecpg/preproc/type.c
   --- a/src/interfaces/ecpg/preproc/type.c	(revision
   a49ac80219c6f28c3cf3973f797de637329952da)
   +++ b/src/interfaces/ecpg/preproc/type.c	(date 1740396929346)
   @@ -395,7 +395,10 @@
    
    				ECPGdump_a_simple(o, name, type->type, type->size, (arr_str_size &&
   strcmp(arr_str_size, "0") != 0) ? arr_str_size : str_neg_one, struct_sizeof,
   prefix, type->counter);
    				if (ind_type != NULL)
   -					ECPGdump_a_simple(o, ind_name, ind_type->type, ind_type->size,
   (arr_str_size && strcmp(arr_str_size, "0") != 0) ? arr_str_size :
   ind_type_neg_one, ind_struct_sizeof, ind_prefix, 0);
   +                {
   +                    Assert(ind_name != NULL);
   +                    ECPGdump_a_simple(o, ind_name, ind_type->type,
   ind_type->size, (arr_str_size && strcmp(arr_str_size, "0") != 0) ?
   arr_str_size : ind_type_neg_one, ind_struct_sizeof, ind_prefix, 0);
   +                }
    
    				free(str_neg_one);
    				free(ind_type_neg_one);
   
   

2. Re: BUG #18848: DEREF_AFTER_NULL.EX.COND After having been compared to a NULL

   Tom Lane <tgl@sss.pgh.pa.us> — 2025-03-14T14:27:07Z

   PG Bug reporting form <noreply@postgresql.org> writes:
   > Looks like there is inconsistency with 'ind_name' and 'int_type' checks. In
   > one place both are checked. In other place only the second one is checked.
   > It's possible that when the second is not NULL the first is also not NULL.
   > If this is so then the problem is not real. But it's hard to prove this. In
   > any case the code needs to be made more clear.
   
   Perhaps it needs to be made more clear, but this patch seems like no
   improvement.  Adding that Assert accomplishes nothing --- the code
   will dump core if ind_name is null, with or without an Assert.
   
   Given the lack of field complaints, I'm inclined to believe there's
   not a bug here.
   
   			regards, tom lane