Re: cleaning perl code
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Noah Misch <noah@leadboat.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-04-11T16:48:50Z
Lists: pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > On 4/11/20 12:30 AM, Noah Misch wrote: >> In summary, among those warnings, I see non-negative value in "Code before >> warnings are enabled" only. While we're changing this, I propose removing >> Subroutines::RequireFinalReturn. Implicit return values were not a material >> source of PostgreSQL bugs, yet we've allowed this to litter our code: > That doesn't mean it won't be a source of problems in future, I've > actually been bitten by this in the past. Yeah, as I recall, the reason for the restriction is that if you fall out without a "return", what's returned is the side-effect value of the last statement, which might be fairly surprising. Adding explicit "return;" guarantees an undef result. So when this does prevent a bug it could be a pretty hard-to-diagnose one. The problem is that it's a really verbose/pedantic requirement for subs that no one ever examines the result value of. Is there a way to modify the test so that it only complains when the final return is missing and there are other return(s) with values? That would seem like a more narrowly tailored check. regards, tom lane
Commits
-
Stop requiring an explicit return from perl subroutines
- 0516f94d18c5 13.0 landed
-
Use perl's $/ more idiomatically
- 8f00d84afc0d 13.0 landed
-
Use perl warnings pragma consistently
- 7be5d8df1f74 13.0 landed