Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt!theory.cs.cmu.edu!tsf
From: tsf@theory.cs.cmu.edu (Timothy Freeman)
Newsgroups: comp.windows.x
Subject: Re: XGetDefaults bug
Message-ID: <1061@theory.cs.cmu.edu>
Date: Mon, 6-Jul-87 21:31:47 EDT
Article-I.D.: theory.1061
Posted: Mon Jul  6 21:31:47 1987
Date-Received: Wed, 8-Jul-87 01:48:55 EDT
References: <1057@theory.cs.cmu.edu> <613@cfa.cfa.harvard.EDU>
Organization: Carnegie-Mellon University, CS/RI
Lines: 28

In article <613@cfa.cfa.harvard.EDU> wyatt@cfa.harvard.EDU (Bill Wyatt) writes:
>Hasn't this come up before? Anyway, it's not a bug, but a feature. The
>entire .Xdefaults file is scanned and stored as a b-tree, and subsequent
>calls do not re-read the file, making accesses MUCH faster. 

It is a bug, because the manual doesn't describe the true behavior of
the routine accurately.

Your comment implies that the bug allows XGetDefault to perform
better.  That isn't true, because XGetDefault could have re-read the
.Xdefaults file each time the first parameter changed.  This would
have resulted in the same performance in the cases where the old
XGetDefault routine was correct, and correct results in all cases.

The version I posted reads the entire .Xdefaults file (including the
lines which appply to irrelevant programs) into the b-tree the first
time XGetDefault is called, and it looks in the tree every time after
the first.  Since every line in the file is represented in the tree,
this yields correct behavior (assuming that the file doesn't change).

How about if you send me net mail if you want to argue about this,
since there probably aren't many people on the net interested in
reading our argument?
-- 
Tim Freeman

Arpanet: tsf@theory.cs.cmu.edu
Uucp:    ...!seismo!theory.cs.cmu.edu!tsf