zsh-workers
 help / color / mirror / code / Atom feed
* zsh/db oddities
@ 2021-09-07  4:29 Bart Schaefer
  2022-06-12 21:19 ` [PATCH] " Bart Schaefer
  0 siblings, 1 reply; 2+ messages in thread
From: Bart Schaefer @ 2021-09-07  4:29 UTC (permalink / raw)
  To: Zsh hackers list

The only example so far is of course zsh/db/gdbm.

Open a database as a global and assign something to it:

% zmodload zsh/db/gdbm
ztie -d db/gdbm -f sample.gdbm sampledb
% sampledb[GLOBAL]=global
% cksum sample.gdbm
3454148649 16384 sample.gdbm

Now start messing with the declaration in a function:

% () {
cksum sample.gdbm
local sampledb
typeset +m sampledb
cksum sample.gdbm
sampledb[INFUNC]=set
cksum sample.gdbm
print $sampledb[INFUNC]
}
3454148649 16384 sample.gdbm
association local sampledb
2087515864 16384 sample.gdbm
2669724292 16384 sample.gdbm
set

As soon as the tied parameter is declared local, the file has been
written, erasing all the existing values.  This seems undesirable?
Returning to the top level:

% cksum sample.gdbm
1634404396 16384 sample.gdbm
% typeset -p sampledb
typeset -A sampledb=( [GLOBAL]=global )

The file has been written again and the original state is back.

If instead you zuntie the local:

% () {
local sampledb
sampledb[LOCAL]=local
zuntie sampledb
}
% typeset -p sampledb
typeset: no such variable: sampledb

Untying the local destroys the global, too, and leaves the file as the
local wrote it.

% ztie -d db/gdbm -f sample.gdbm sampledb
% typeset -p sampledb
typeset -A sampledb=( [LOCAL]=local )

I think the correct thing might be to prohibit changing the scope,
similar to what happens when an attempt is made to remove the readonly
attribute?

% ztie -r -d db/gdbm -f sample.gdbm sampledb
% () {
local -A +r sampledb
}
(anon):local:1: sampledb: can't change type of a special parameter

Re-ztie-ing the database file while it is still tied, is already
handled as an error.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [PATCH] Re: zsh/db oddities
  2021-09-07  4:29 zsh/db oddities Bart Schaefer
@ 2022-06-12 21:19 ` Bart Schaefer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 2022-06-12 21:19 UTC (permalink / raw)
  To: Zsh hackers list

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

Returning to this 8+ months later ...

On Mon, Sep 6, 2021 at 9:29 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Open a database as a global and assign something to it:
> [...]
> Now start messing with the declaration in a function:
> [...]
> As soon as the tied parameter is declared local, the file has been
> written, erasing all the existing values.  This seems undesirable?
> [...]
> Untying the local destroys the global, too, and leaves the file as the
> local wrote it.
> [...]
> I think the correct thing might be to prohibit changing the scope,
> similar to what happens when an attempt is made to remove the readonly
> attribute?
> [...]
> Re-ztie-ing the database file while it is still tied, is already
> handled as an error.

Looking into how this might be accomplished, I noticed this:

#ifndef PM_UPTODATE
#define PM_UPTODATE     (1<<19) /* Parameter has up-to-date data (e.g.
loaded from DB) */
#endif

I don't think that's a safe choice of bitflag any more?  That was
introduced 2017-02-16, but the PM_ bit values were rearranged
2018-10-12 and bit 19 is now PM_LOCAL.  That doesn't have any effect
on the aforementioned behavior of "local"/"zuntie", but perhaps
something like this is better?

-#ifndef PM_UPTODATE
-#define PM_UPTODATE     (1<<19) /* Parameter has up-to-date data
(e.g. loaded from DB) */
+#ifndef PM_UPTODATE /* Parameter has up-to-date data (e.g. loaded from DB) */
+#define PM_UPTODATE     PM_DONTIMPORT_SUID     /* Safe PM_ bit to re-use */
 #endif

Back on the original issue, the simplest way to fix this appears to be
to declare the ztie'd parameters to be PM_SINGLE.

% zmodload zsh/db/gdbm
ztie -d db/gdbm -f sample.gdbm sampledb
% () {
local sampledb
typeset +m sampledb
}
(anon):local:2: sampledb: can only have a single instance
%

Patch attached.  Comments welcome.

[-- Attachment #2: gdbm.txt --]
[-- Type: text/plain, Size: 909 bytes --]

diff --git a/Src/Modules/db_gdbm.c b/Src/Modules/db_gdbm.c
index 7e11ec939..3fefd412b 100644
--- a/Src/Modules/db_gdbm.c
+++ b/Src/Modules/db_gdbm.c
@@ -34,8 +34,8 @@
 #include "db_gdbm.mdh"
 #include "db_gdbm.pro"
 
-#ifndef PM_UPTODATE
-#define PM_UPTODATE     (1<<19) /* Parameter has up-to-date data (e.g. loaded from DB) */
+#ifndef PM_UPTODATE /* Parameter has up-to-date data (e.g. loaded from DB) */
+#define PM_UPTODATE     PM_DONTIMPORT_SUID	/* Safe PM_ bit to re-use */
 #endif
 
 static Param createhash( char *name, int flags );
@@ -111,7 +111,7 @@ bin_ztie(char *nam, char **args, Options ops, UNUSED(int func))
     struct gsu_scalar_ext *dbf_carrier;
     char *resource_name, *pmname;
     GDBM_FILE dbf = NULL;
-    int read_write = GDBM_SYNC, pmflags = PM_REMOVABLE;
+    int read_write = GDBM_SYNC, pmflags = PM_REMOVABLE|PM_SINGLE;
     Param tied_param;
 
     if(!OPT_ISSET(ops,'d')) {

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-06-12 21:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-07  4:29 zsh/db oddities Bart Schaefer
2022-06-12 21:19 ` [PATCH] " Bart Schaefer

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).