| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: for loop variable fixes |
| Date: | 2026-06-23 14:12:14 |
| Message-ID: | 689168.1782223934@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> I have noticed that many for loops have loop variables whose type
> doesn't match the upper-bound condition. Meaning, if you have
> for (i = 0; i < foo; i++)
> then the type of i should ordinarily be the same as the type of foo.
+1 for improving this --- I was annoyed about it just yesterday
with respect to resowner.c. It looks to me like just about every
single instance of "for (int ..." in that file is wrong because
what's being compared to is unsigned. I see that your patch gets
a couple of those places, but only a couple, which makes me wonder
what -Wsign-compare is checking exactly.
> As far as I can tell, none of of these are current bugs, but this is the
> kind of thing that sets bad precedents and could lead to truncated
> values or unintended overflows etc. in the future.
Right. For resowner.c, I don't think the compared-to values can
actually reach INT_MAX, but that doesn't make this good code.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-06-23 14:28:18 | Re: Row pattern recognition |
| Previous Message | Marcos Pegoraro | 2026-06-23 14:03:08 | Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements |