Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not

Z wrote:
George Cook wrote:
All the code I
have ever seen which uses XtAppAddTimeOut either validates the timer
or has a safety check for zero.

"Validate the timer?"

Is there an Xt...() function that can validate the timer?


Is the timer null? If it is, it's not valid, and it's a bug in the calling code.

Does the calling code stackdump when the caller passes in a bogus argument value? If so, then that is a bug in the called code, and secondary to the bug in the calling code.

Can we spend our time validating stuff further? Sure. I've been known to calculate an MD5 or a CRC32 for data structures, but that's overkill for most applications. And it's probably overkill for this one. I know of no standard X call that can verify the XtIntervalId value as being valid, which means the application is left to maintain it. Without such a mechanism for checking the integrity, the programmer is left to use wrappers and local validation (up to and including comparatively drastic measures such as checksumming the data structures), or to simply assume validity and blindly charge forward. Being that this is X Windows involved here and given that X Windows itself traditionally assumes error-free operations, the usual and normally-recommended solution is reduce the bugs where identified and feasible, and to blindly charge forward.

Architectural changes to X Windows (to verify these structures, and to provide argument checking) is rather unlikely, as it involves detailed modifications to a gazillion internal and external X calls. (Should this have been part of the original MIT design? Probably. But we're way past that point now...)

The obvious steps here are to avoid passing in bad data (which fixes the problem in the calling code), and to get a formal report into the support center logged in, such that the response to an argument-passing failure within the called code isn't a stackdump (which fixes the misbehaviour of the called code -- but do remember, fixing the stackdump in the X call here doesn't and won't fix the bug in the calling application code.)

I know that the folks on the DECwindows team are at least somewhat aware of this case right now, but the formal report is how the loop is closed for the contract support customer sites; how fixes are propagated back out. But the central fix here involves fixing the application code, regardless of any changes to DECwindows that might allow it to more gracefully field this particular case.



.

Relevant Pages