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>