On Thu, Nov 27, 2025 at 4:58 PM Amul Sul wrote:
> On Thu, Nov 27, 2025 at 6:48 AM Amit Langote wrote:
> > On Thu, Nov 27, 2025 at 7:59 AM Michael Paquier wrote:
> > > On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote:
> > > It seems to me that it is important to keep documented the overfl
On Thu, Nov 27, 2025 at 6:48 AM Amit Langote wrote:
>
> On Thu, Nov 27, 2025 at 7:59 AM Michael Paquier wrote:
> > On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote:
> > > On Wed, Nov 26, 2025 at 5:41 PM Amit Langote
> > > wrote:
> > >> []
> >
> > It seems to me that it is important
On Thu, Nov 27, 2025 at 10:28 AM Michael Paquier wrote:
> On Thu, Nov 27, 2025 at 10:18:38AM +0900, Amit Langote wrote:
> > I’m fine with updating all core callers to use the new *_safe(... Node
> > *escontext) APIs all in one patch. However, we could consider keeping
> > the existing *_opt_overfl
On Thu, Nov 27, 2025 at 10:18:38AM +0900, Amit Langote wrote:
> I’m fine with updating all core callers to use the new *_safe(... Node
> *escontext) APIs all in one patch. However, we could consider keeping
> the existing *_opt_overflow() functions as thin wrappers over the new
> ones, to avoid bre
On Thu, Nov 27, 2025 at 7:59 AM Michael Paquier wrote:
> On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote:
> > On Wed, Nov 26, 2025 at 5:41 PM Amit Langote
> > wrote:
> >> * The rename from *_opt_overflow to *_overflow_safe could be made a
> >> separate patch (say 0002), so it can be dis
On Wed, Nov 26, 2025 at 06:40:38PM +0530, Amul Sul wrote:
> On Wed, Nov 26, 2025 at 5:41 PM Amit Langote wrote:
>> * The rename from *_opt_overflow to *_overflow_safe could be made a
>> separate patch (say 0002), so it can be discussed separately. For
>> example, whether to keep the old *_opt_ove
On Wed, Nov 26, 2025 at 5:41 PM Amit Langote wrote:
>
> Hi,
>
> On Wed, Nov 26, 2025 at 8:43 PM Michael Paquier wrote:
> > On Wed, Nov 26, 2025 at 03:09:25PM +0530, Amul Sul wrote:
> > > This continues the previous refactoring commit [1] where we adopted
> > > soft error reporting for some numeri
On Wed, Nov 26, 2025 at 5:13 PM Michael Paquier wrote:
>
>
> Hmm. Following the previous example you have quoted, I am wondering
> if we'd tweak the names a bit differently. Rather than the
> popo_overflow_safe() pattern from your patch, I would choose a simpler
> popo_safe() as naming conventio
Hi,
On Wed, Nov 26, 2025 at 8:43 PM Michael Paquier wrote:
> On Wed, Nov 26, 2025 at 03:09:25PM +0530, Amul Sul wrote:
> > This continues the previous refactoring commit [1] where we adopted
> > soft error reporting for some numeric functions. This patch applies
> > the same pattern to the date/t
On Wed, Nov 26, 2025 at 03:09:25PM +0530, Amul Sul wrote:
> This continues the previous refactoring commit [1] where we adopted
> soft error reporting for some numeric functions. This patch applies
> the same pattern to the date/timestamp function. The change ensures
> consistency by utilizing the
Hi,
The attached patch proposes to use soft error reporting infrastructure
for the date/timestamp conversion function, which currently depends on
integer variables to control error throwing.
This continues the previous refactoring commit [1] where we adopted
soft error reporting for some numeric
11 matches
Mail list logo
