On Tue, 16 Jul 2024 22:19:05 +0300 Nikita Kiryushin <kiryus...@ancud.ru> wrote:
> On 7/16/24 12:45, Alexey Khoroshilov wrote: > > Yes, but there is another possible modification: replacement of call to > > nonseekable_open() by a call to some other function that returns error. > > Current code is already ready for such modification. > > The change of which function is called would change the behavior indeed, but, > TBH, I do not see it as a valid point: If we assume that nonseekable_open() > changes to something else in the future, we may assume as well that some > other call will be > added later with a risk of resource leaking. This is a thing, that whoever > would do > such changes should be careful about. > > For me, the code as it is now, is not uniform with the other places that use > nonseekable_open(). The point is moot. If something returns a value, even if it says it will never return failure, there's no harm in checking it. If we ignore the return value, that is a unneeded coupling of design between the function and its users. It does no harm in checking the value, so I rather just keep doing so. -- Steve
