Re: mapfile and unset: Does this actually work?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Feb 4, 2024 at 10:04 AM Mark J. Reed <markjreed@xxxxxxxxx> wrote:
>
> I take that back. If the file is nonempty, then the file is deleted. If the file is empty, then it's not. So it seems to be an conflation of unset and empty in the mapfile logic.

Aha.  In the "get" method from the gsu struct:

    /* Set u.str to contents of file given by name */
    if ((contents = get_contents(pm->node.nam)))
        pm->u.str = contents;
    else {
        pm->u.str = "";
        pm->node.flags |= PM_UNSET;
    }

So an empty file always appears to [already] be unset, e.g.

 % touch empty
 % zmodload zsh/mapfile
 % print ${+mapfile[empty]}
 0

This in turn appears to be because get_contents() doesn't distinguish
a file it can't open from one whose contents it can't read.  More
specifically, mmap() on an empty file returns -1.

The unset logic in mapfile.c is never called because the parameter is
already marked unset.

Perhaps this is more suited for the BUGS file than for an immediate repair.