Possible fault with resolve column name (plpgsql)

Started by Ranier Vilelaover 4 years ago3 messages
#1Ranier Vilela
ranier.vf@gmail.com
1 attachment(s)

Hi,

Found by llvm scan build.
Argument with 'nonnull' attribute passed null pl/plpgsql/src/pl_comp.c
resolve_column_ref

Proceed?

regards,
Ranier Vilela

Attachments:

fix_possible_fault_resolve_columnname_plpgsql.patchapplication/octet-stream; name=fix_possible_fault_resolve_columnname_plpgsql.patchDownload
 /*
diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c
index f5b1d5c4fa..96fcfe186c 100644
--- a/src/pl/plpgsql/src/pl_comp.c
+++ b/src/pl/plpgsql/src/pl_comp.c
@@ -1215,6 +1215,7 @@ resolve_column_ref(ParseState *pstate, PLpgSQL_expr *expr,
 
 				Assert(IsA(field1, String));
 				name1 = strVal(field1);
+				colname = name1;
 				nnames_scalar = 1;
 				nnames_wholerow = 1;
 				break;
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ranier Vilela (#1)
Re: Possible fault with resolve column name (plpgsql)

Ranier Vilela <ranier.vf@gmail.com> writes:

Found by llvm scan build.
Argument with 'nonnull' attribute passed null pl/plpgsql/src/pl_comp.c
resolve_column_ref

This is somewhere between pointless and counterproductive. colname won't
be used unless the switch has set nnames_field (and the identified number
of names matches that). If that logic somehow went wrong, I'd *want*
the later strcmp to dump core, not possibly give a false match.

regards, tom lane

#3Ranier Vilela
ranier.vf@gmail.com
In reply to: Tom Lane (#2)
Re: Possible fault with resolve column name (plpgsql)

Em qui., 16 de set. de 2021 às 17:05, Tom Lane <tgl@sss.pgh.pa.us> escreveu:

Ranier Vilela <ranier.vf@gmail.com> writes:

Found by llvm scan build.
Argument with 'nonnull' attribute passed null pl/plpgsql/src/pl_comp.c
resolve_column_ref

This is somewhere between pointless and counterproductive.

Not if you've ever used llvm scan, but it's pretty accurate in identifying
what the condition might occur.

colname won't
be used unless the switch has set nnames_field (and the identified number
of names matches that).

13
← <#Path12>
Assuming field 'type' is equal to T_String
→ <#Path14>

22
← <#Path21>
Assuming 'nnames' is equal to 'nnames_field'
→ <#Path23>

If that logic somehow went wrong, I'd *want*

the later strcmp to dump core, not possibly give a false match.

In this case, strcmp will fail silently, without any coredump.

If we have a record, and the field is T_String, always have a true match?

regards,
Ranier Vilela