On 19.02.2024 06:07, George Dunlap wrote:
> On Wed, Feb 14, 2024 at 7:42 PM Roger Pau Monne wrote:
>>
>> It's not obvious from the function itself whether the incremented value will
>> be
>> stored in the parameter, or returned to the caller. That has leads to bugs
>> in
>> the past as callers
On Wed, Feb 14, 2024 at 7:42 PM Roger Pau Monne wrote:
>
> It's not obvious from the function itself whether the incremented value will
> be
> stored in the parameter, or returned to the caller. That has leads to bugs in
> the past as callers assume the incremented value is stored in the paramet
On Wed, Feb 14, 2024 at 02:42:46PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > It's not obvious from the function itself whether the incremented value
> > will be
>
> s/the function itself/just the function name/ ?
>
> > stored in the parameter, or returned to the
On 14.02.2024 11:37, Roger Pau Monne wrote:
> It's not obvious from the function itself whether the incremented value will
> be
s/the function itself/just the function name/ ?
> stored in the parameter, or returned to the caller. That has leads to bugs in
> the past as callers assume the increm
Hi,
On 14/02/2024 10:37, Roger Pau Monne wrote:
It's not obvious from the function itself whether the incremented value will be
stored in the parameter, or returned to the caller. That has leads to bugs in
the past as callers assume the incremented value is stored in the parameter.
Add the __m
It's not obvious from the function itself whether the incremented value will be
stored in the parameter, or returned to the caller. That has leads to bugs in
the past as callers assume the incremented value is stored in the parameter.
Add the __must_check attribute to the function to easily spot
