public inbox for [email protected]  

help / color / mirror / Atom feed

From: Zsolt Parragi <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: A stack allocation API
Date: Wed, 18 Mar 2026 19:54:00 +0000
Message-ID: <CAN4CZFOe-z0uYgZm1JGPRPOR6DzxAr82O+Gg97_RvdGTDXU3FQ@mail.gmail.com> (raw)
In-Reply-To: <CA+hUKG+Ovn6cWxCTjTAdQLmMksg_BfDfDOr6qPRFZbbQz9vFyQ@mail.gmail.com>
References: <CA+hUKG+ixUUYOGRcuZpkk5pmJZaUQv6VCPAjdTZXFP5vA8jxcA@mail.gmail.com>
	<[email protected]>
	<CA+hUKG+Shdfa_QcVWXrHyhWGDJcPsw2aXWRQxnaUpyUa2fMffA@mail.gmail.com>
	<CA+hUKG+Ovn6cWxCTjTAdQLmMksg_BfDfDOr6qPRFZbbQz9vFyQ@mail.gmail.com>

Hello!

+ !defined(PG_STACK_USE_ALLOC) &&

There's a typo there, that should be ALLOCA?

+/* Just use palloc. */
+#ifdef PG_STACK_USE_PALLOC
+#define DECLARE_PG_STACK_IMPL(size)
+#define pg_stack_alloc_aligned_impl(size, align) \
+ pg_stack_palloc_aligned((size), (align))
+#define pg_stack_ptr_p() false
+#endif

Isn't a ptr parameter missing from this branch?

+#define pg_stack_strdup_with_len(data, size) \
+ (pg_stack_sanity_checks(1), \
+ pg_stack_let_size = (size), \
+ pg_stack_strdup_with_len_impl( \
+ pg_stack_alloc_aligned_impl(pg_stack_let_size + 1, \
+ alignof(char)),

Both seems like a not realistic edge case, but since the array macros
above have a length check, shouldn't this also guard against +1
overflowing?

+/* Populate and insert a new entry. */
+static inline void *
+pg_stack_debug_link(pg_stack_debug_node **head,
+ pg_stack_debug_node *node,
+ void *ptr,
+ size_t size)
+{
+ node->ptr = ptr;
+ node->size = size;

Again unrealistic edge case, but if the above macros have overflow
checks for typically 64 bit size_t, shouldn't this also have some
safety checks, or at least setting node->size consistently to uint32_t
max if size is bigger?


+#define pg_stack_strdup(cstr) \
+ pg_stack_strdup_with_len((cstr), strlen(cstr))
+#define pg_stack_strndup(cstr, n) \
+ pg_stack_strdup_with_len((cstr), strnlen((cstr), (n)))

+#define pg_stack_text_to_cstring(text) \
+ pg_stack_strdup_with_len(VARDATA_ANY(text), VARSIZE_ANY_EXHDR(text))
+#define pg_stack_text_datum_to_cstring(datum) \
+ pg_stack_text_to_cstring((text *) DatumGetPointer(datum))

I would at least very clearly document that these macros evaluate
their arguments twice. I can't think of any scenario that would
seriously break things with them (or at least not break the stack),
but it could be still easy to forget that these are macros and not
functions.

Or can't they work similarly to DECLARE_PG_STACK_SIZE and store the
pointer in a local variable?

view thread (6+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: A stack allocation API
  In-Reply-To: <CAN4CZFOe-z0uYgZm1JGPRPOR6DzxAr82O+Gg97_RvdGTDXU3FQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox