jhc@ivan.uucp (James H. Coombs) (02/14/91)
In the man page for XtAddInput()/XtAppAddInput(), I don't see any error condition to check for. The call returns an XtInputId, and I suppose that I am to treat that as opaque information. Is that right? I checked the source code, but I would like some verification on this. In the source (for X11R4), I found that XtAppErrorMsg() is called if the condition mask is invalid. That seems fair enough. But, I see a subsequent call to XtNew(), which calls malloc(). XtAddInput() then uses the result without checking for a valid pointer. It is this pointer that is returned as the XtInputId. Putting aside the fact that the current implementation of XtAddInput() will crash if the allocation fails, should I check for a NULL return? or should this truly be considered opaque? Is this an issue specific to XtAddInput()? or is there just a programming lapse in that routine? or is it a lapse in the documentation? In other words, should I just assume that all undocumented errors will be fatal? It seems inappropriate to check the source code and then check for returns based upon the current implementation. Thanks. --Jim
jhc@irwin.uucp (James H. Coombs) (02/14/91)
In article <64840@brunix.UUCP> jhc@ivan.uucp (James H. Coombs) writes: >In the man page for XtAddInput()/XtAppAddInput(), I don't see any error >condition to check for. The call returns an XtInputId, and I suppose >that I am to treat that as opaque information. Is that right? I >checked the source code, but I would like some verification on this. Actually, the problem is a little deeper than I first thought. I need to keep a table of descriptor-XtInputId mappings. In order to determine whether or not I have called XtAddInput() for a descriptor, I need to know the null/zero/notset value for XtInputId. If I don't have that, then I have to maintain a boolean in addition. This seems like a lot of extra mechanics just to check on an id. Perhaps what we need is for the documentation to say OPAQUE if it really is opaque. In general, however, it seems unlikely that committing Xt to zero/non-zero would create any hardships in development. While I am at it, I may as well complain about the fact that XtAddInput() takes a XtPointer for the condition. In fact, this is an XtInputMask that is cast to an XtPointer and then back to an XtInputMask in the implementatation of XtAddInput(). Note that you do not actually provide the *address* of the mask; instead, you set an XtInputMask and cast it to an XtPointer for a routine that really wants an input mask. This is confusing at the least. Or, perhaps someone can clarify the role of XtPointer. Is there some general principle that I am missing? Thanks. --Jim
pete@iris49.UUCP (Pete Ware) (02/15/91)
jim> But, I see a subsequent call to XtNew(), which calls malloc(). jim> XtAddInput() then uses the result without checking for a valid jim> pointer. It is this pointer that is returned as the XtInputId. jim> Putting aside the fact that the current implementation of jim> XtAddInput() will crash if the allocation fails, should I check jim> for a NULL return? or should this truly be considered opaque? XtMalloc() calls XtErrorMsg() if the allocation fails. For better or worse, XtErrorMsg() is for fatal errors and the application exits. In other words, XtMalloc() exits instead of returning NULL. --pete Pete Ware / Biosym / San Diego CA / (619) 546-5532 uucp: scripps.edu!bioc1!pete Internet: bioc1!pete@scripps.edu
jhc@irwin.uucp (James H. Coombs) (02/15/91)
In article <9102141628.AA03719@iris49.biosym.com> pete@iris49.UUCP (Pete Ware) writes: >jim> But, I see a subsequent call to XtNew(), which calls malloc(). >jim> XtAddInput() then uses the result without checking for a valid >jim> pointer. It is this pointer that is returned as the XtInputId. > >XtMalloc() calls XtErrorMsg() if the allocation fails. For better or >worse, XtErrorMsg() is for fatal errors and the application exits. In >other words, XtMalloc() exits instead of returning NULL. I see that now, thanks. But that still leaves the issue of testing a table for an "unset" value. Is it appropriate for me to test for NULL? I know that XtAddInput() will never return NULL, but I don't see that in the documentation. That means that the implementation could be changed to return some other datatype--in which 0 might be valid--and my code will break. The same problem comes up with XtAppAddWorkProc(). I am looking for a general principle. Is it that there are no error returns? Is it that errors always call the fatal error handler? And, if that is true, is it that all data is opaque---that there is no value that I can test for to see whether or not something has been set? (I pursue these questions because we are trying to standardize our coding style, including error handling.) Thanks. --Jim
asente@adobe.com (Paul Asente) (02/16/91)
In article <65118@brunix.UUCP> jhc@irwin.UUCP (James H. Coombs) writes: >I am looking for a general principle. Is it that there are no error >returns? Is it that errors always call the fatal error handler? And, >if that is true, is it that all data is opaque---that there is no value >that I can test for to see whether or not something has been set? Unless explicitly stated otherwise, you can assume that Intrinsics functions always return correct data. Error conditions are handled by calling the error handler. An example of a case where an error is indicated by the return value and not by calling the error handler is XtNameToWidget; the spec states in section 11.2, "If no match is found, return NULL." Similarly, you can't make assumtions about 0 being valid or invalid unless the spec says so. An implementation would be free to return as an XtInputId an index into a table, making 0 a perfectly legal return value. -paul asente asente@adobe.com ...decwrl!adobe!asente
pete@iris49.UUCP (Pete Ware) (02/19/91)
Reading the documentation, it looks like there is no way to check for an error return value from XtAddInput(). Seeing that XtInputId is: typedef unsigned long XtInputId; means zero is the most likely thing that could be an error return value but no indication that it is an error. As far as general principles, if a function does not have an error return value, it _probably_ means the author didn't think there were any significant errors to return. It could also mean the documentation isn't upto date w.r.t. to the source. A large percentage of the intrinsics are void functions so most do not need any checking. The remaining ones usually return useful information such as Boolean values, the previous error handler, etc, that you are probably going to use right away and may not have an error condition (i.e functions returning a Boolean value or function pointers). The only exception to this are ones that return Widgets. I think the toolkit was defined to make it easy to program and not have to be constantly checking for errors. Most errors are treated either as fatal (out of memory) or reported and recovered from internally. --pete Pete Ware / Biosym / San Diego CA / (619) 546-5532 uucp: scripps.edu!bioc1!pete Internet: bioc1!pete@scripps.edu