Re: fgetname function?

[Paul Eggert]

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.