|
|
Subscribe / Log in / New account

Flags as a system call API design pattern

Flags as a system call API design pattern

Posted Feb 13, 2014 12:49 UTC (Thu) by sorokin (guest, #88478)
Parent article: Flags as a system call API design pattern

I wonder why function for atomically swapping two existing files is renameat2() with special flag and not swapat().

Using flags to completely change function semantic is a bad thing I suppose.


to post comments

Flags as a system call API design pattern

Posted Feb 13, 2014 14:25 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

What is renameat2's behavior with paths that reside on different filesystems? I'd assume it fails due to the atomicity guarantees it can no longer make. Since rename already has some restrictions in that regard, swapat sounds, to me, like it might not care by default (and would need a flag for atomicity).

As for behavior change based on flags, one coworker was working with a tool which output to stdout/stderr by default, was silent with -E (no argument), but -EE took an argument for where to write the output (but just the output data from the conversion, not logging), so there's some insanity out there. I hope the kernel avoids such...behavior for a single syscall (outside of *ctl calls).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds