From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pve-devel] [PATCH common v2 1/3] JSONSchema: add support for array parameter in api calls, cli and config
Date: Tue, 6 Jun 2023 14:05:22 +0200 [thread overview]
Message-ID: <hawckdxlhlazshp4mc7dov5rsky7hpmso4g33xig3onynb34lo@xk2olb7urnob> (raw)
In-Reply-To: <3f88f726-9d89-3026-2a2c-4b3e9dbda7db@proxmox.com>
On Tue, Jun 06, 2023 at 12:45:57PM +0200, Thomas Lamprecht wrote:
> Am 06/06/2023 um 11:41 schrieb Dominik Csapak:
> >>> +my $untaint_recursive;
> >>
> >> I got flash backs w.r.t. refcount cycles here keeping all variables, and thus memory
> >> inside the body alive forever, don't we need a weaken?
> >>
> >> E.g., like we had to do in PVE::Status::Graphite's assemble.
> >
> > mhmm isn't that because there we use variables from outside the
> > function? here we only use the parameters themselves
>
> I'm not 100% sure about the details, but since then, seeing something like
> this pattern triggers my cycle instincts, I'd like to have that checked out
> closely.
I *do* prefer `my sub` these days.
However, for recursive subs you need to `use feature 'current_sub'` to
avoid ... well... leaks ;-)
So:
my sub untaint_recursive : prototype($) {
use feature 'current_sub';
my ($arg) = @_;
...
# For recursion:
__SUB__->($stuff);
...
}
Given that this function shouldn't be leaky, you could keep it, or even
pre-declare the sub to allow recursion:
my sub untaint_recursive : prototype($);
sub untaint_recursive : prototype($) {
<regular code>
}
however, `perlsub` explicitly states that this, too, can leak ;-)
next prev parent reply other threads:[~2023-06-06 12:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 8:39 [pve-devel] [PATCH common/http/guest-common/qemu-server v2] schema/config array support Dominik Csapak
2023-06-06 8:39 ` [pve-devel] [PATCH common v2 1/3] JSONSchema: add support for array parameter in api calls, cli and config Dominik Csapak
2023-06-06 9:12 ` Thomas Lamprecht
2023-06-06 9:41 ` Dominik Csapak
2023-06-06 10:45 ` Thomas Lamprecht
2023-06-06 11:19 ` Dominik Csapak
2023-06-06 11:24 ` Thomas Lamprecht
2023-06-06 12:05 ` Wolfgang Bumiller [this message]
2023-06-06 8:39 ` [pve-devel] [PATCH common v2 2/3] section config: implement array support Dominik Csapak
2023-06-06 8:39 ` [pve-devel] [PATCH common v2 3/3] JSONSchema: disable '-alist' format Dominik Csapak
2023-06-06 8:39 ` [pve-devel] [PATCH http-server v2 1/2] proxy request: forward json content type and parameters Dominik Csapak
2023-06-06 8:39 ` [pve-devel] [PATCH http-server v2 2/2] use proper arrays for array parameter Dominik Csapak
2023-06-06 8:39 ` [pve-devel] [PATCH guest-common v2 1/1] vzdump: change 'exclude-path' from alist to an array format Dominik Csapak
2023-06-06 8:39 ` [pve-devel] [PATCH qemu-server v2 1/1] api: switch agent api call to 'array' type Dominik Csapak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=hawckdxlhlazshp4mc7dov5rsky7hpmso4g33xig3onynb34lo@xk2olb7urnob \
--to=w.bumiller@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox