>> >> To answer your question on "coping with both planned and unexpected >> additions" I don't think I have a complete answer yet. Any suggestions in >> addition to what you've already mentioned are definitely more than >> welcome!!! > I've been trying to suggest three different possible approaches. I was > hoping that you'd be able to look at the suggestions and determine if > one worked better than the rest. I'll summarize if it helps.
I think I did say in addition to what you had already mentioned. I did not say these were not appropriate or that I didn't like them, nor that I wasn't looking at them. All I was stating was that any other thoughts were also welcome... > > 1. Create structures that contain type information, so it's possible to > determine what you're looking at when you get the structure. > > 2. You can take an approach similar to the way the sockets code copes > with different error messages. The catch with this is that your > accessor functions need to be able to determine the type of object that > you're looking at. > > 3. Declare the err_info_t entirely opaque and use an accessor > function based interface to get new properties as you add them. These make sense and, as stated in my email from earlier today, I'm already in the process of changing the document to reflect what has been suggested. This includes the idea of an error type associated with the structure so we can add more types at a later time as well as attaching this to a library descriptor that would include this error information. -evan
