Date: Thu, 19 Sep 2002 15:44:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Bruce Evans <bde@zeta.org.au>, Julian Elischer <julian@elischer.org>, Edwin Culp <eculp@encontacto.net>, current@FreeBSD.ORG Subject: Re: slapd dumping core with today's current. Message-ID: <3D8A5338.363AEF4B@mindspring.com> References: <Pine.GSO.4.10.10209191821440.27171-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote:
> That's kind of the point of adding the fields that we did
> (mc_len, mc_fpformat). They can be used to help validate
> the contents and to allow extensions. We also have some
> spare slots, but the last incarnation of ucontext_t also
> had spare slots and it wasn't nearly enough for what we
> now need.
I was thinking more along the lines of:
struct extend {
struct extend *next; /* Next extension in list */
int32_t id; /* extension ID */
char crap[1]; /* extension specific data */
};
And then adding:
struct extend *extensions;
Yeah, if it's non-NULL, it means a linear list traversal to find
relevent extensions, but that's better than non-working.
String-to-id translation is a seperate function, and can also use
a linear list traversal to find the string, get an ID back, and
then subsequqnetly use the ID. Yeah, it's an extra contents
dereference, but it's better than non-working.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D8A5338.363AEF4B>