On Sunday, 01 April 2007 at 11:04, Rocco Rutte wrote: > Hi, > > * Kyle Wheeler [07-04-01 00:31:56 -0600] wrote: > > On Friday, March 30 at 03:29 PM, quoth Rocco Rutte: > >>> So... you're telling me that pointers are no longer stored in the > >>> hcache? Mutt (with hcache) no longer relies on malloc returning > >>> predictable results? > > >> No. Pointers are still stored. We don't really update the hcache so > >> that pointers could be an issue. > > > ... I guess you mean that pointers aren't *restored*? > > They are both: stored and restored. Storing a message happens is just > right after it got fetched from the server so that at that point there > isn't data behind those pointers, they're just NULL. After reading the > message from the cache, mutt gets NULL pointers all the time and thus > behaves exactly as it would without the cache because the message is > the same as it was after the fetch. > > That's why it's so difficult to fix the issue because we need to > identify which pointers may contain garbage and which don't. > > My first approach (which was rejected) was with a whitelist, i.e. > storing only pointers we also dump/restore data for. The right approach > was considered to be a blacklist one that only sets "dangerous" > pointers to NULL. I failed to implement that because of the above > reason. Hence the issue is still open... I can't remember the details of the last go-round, but at this point I think it's fine to just copy known fields into the cache. The objection I remember is that I wanted the fixup to happen on store instead of fetch, since the cache will be read far more than it is written.
Attachment:
pgpsIKm611vXo.pgp
Description: PGP signature