On 2022-12-11 18:41, Bruno Haible wrote:
Also, it would be prone to races, and thus discouraged for functional
code. But it might be a useful addition for debugging code.

Also, it wouldn't work for files that have never had a name (e.g., ordinary pipes) - unless we want to create a special syntax for nameless files, useful for debugging but not as file names (I assume we'd use GNU/Linux's syntax?). And similarly I suppose we'd replicate GNU/Linux behavior for nameless but formerly-named files that have been deleted but are still open. It could be a bit tricky with FDs open to symlinks, or with files that have been reattached into the file system, but I assume there are solutions to all that.

it might be a useful addition for debugging code

If non-debugging modules don't depend on it, this sounds like it may well be useful for debugging.

I haven't felt much of a need for this sort of function myself, though I expect that's partly luck and perhaps partly my debugging style. For example, although fgetname would have been a nicety for the du issue prompting the recent Gnulib change, the most important thing was logging device and inode numbers; the names weren't as important since they were deducible from the other output.


Reply via email to