On Thu, Nov 09, 2023 at 05:48:57PM +0100, Thomas Haller wrote: > On Thu, 2023-11-09 at 16:32 +0100, Pablo Neira Ayuso wrote: > > On Thu, Nov 09, 2023 at 04:19:29PM +0100, Thomas Haller wrote: > > > On Thu, 2023-11-09 at 16:14 +0100, Pablo Neira Ayuso wrote: > > > > > > > > Add a wrapper function, no macro. > > > > > > > > > > > > > memory_allocation_error() is itself a macro, as it uses > > > __FILE__,__LINE__ > > > > In this case above, __FILE__ and __LINE__ does not provide much > > information? > > In which case? The patch changes a repeated pattern to a macro(), > without changing any behavior and without questioning the use of > __FILE__:__LINE__. > . > > > nftnl_expr_alloc() returns NULL when support for an expression is > > missing in libnftnl, > > The patch is not about nftnl_expr_alloc(). Do you mean > nftnl_udata_buf_alloc()? > > nftnl_udata_buf_alloc() fails exactly when malloc() fails. It's > unrelated to missing "support for an expression". > > > that provides a hint on that, this is very rare > > and it can only happen when developing support for new expressions. > > > > Maybe simply say __func__ instead to know what function has failed > > when performing the memory allocation is a hint that is fine enough. > > I wouldn't use __func__. It consumes more strings in the binary while > providing less exact information. OK, then if you prefer a generic OOM error message, that's also fine.
