NICE Eiffel Standards Group -- Library Committee Mailing List To post to list: NICE-ESG-Libs@atlanta.twr.com To send mail to the Chairman of the committee: NICE-ESG-Libs-chair@atlanta.twr.com Administrative matters (sign up, unsubscribe, mail problems, etc): NICE-ESG-Libs-request@atlanta.twr.com
Date: Fri, 2 Jun 95 18:35:12 PDT From: bertrand@vienna.eiffel.com (Bertrand Meyer) Subject: Serious library problem To: nice.lib@vienna.eiffel.com, Steve_Tynor@vienna.eiffel.com, Copy to: From: Bertrand Meyer Mailer: BOOM Dear Colleagues: We just encountered a major problem with a PELKS feature that we initially approved. (This is another example, by the way, of why it is essential to have proposed extensions or changes implemented and tested extensively before being put into the standard. We didn't see anything wrong with the feature when it was first introduced into the PELKS. We have made a big effort to implement as much of the PELKS as we could, partly to avoid such disasters while there is still time.) The problem is `to_pointer', especially in STRING. We used to have `to_c', returning a result of type ANY; the PELKS says to_pointer: POINTER is -- A pointer to a C form of current string. -- Useful only for interfacing with C software. This may have sounded good at first but is impossible for an object-moving implementation. (We found out when a user of our pre-release based on the PELKS reported a GC bug.) If ``a C form of current string'' is interpreted to mean the actual special object that contains the string (not a C copy), as it seems to do, then this is an Eiffel object. If the client software assigns the value of `to_pointer' to (say) a C variable, and later uses the value of that variable, the object may have moved, so the value will be wrong and disaster will follow. This is a show-stopper. With a result of type ANY we don't have this problem since it will be a reference, of which the GC can keep track. Such a use of POINTER seems wrong anyway on further examination. POINTER was designed for pointers to external objects, not Eiffel objects. To pass Eiffel objects to external software, one can use the $ operator. We have removed `to_pointer' from our implementation since it is likely to cause crashes. The only form of `to_pointer' that is implementable for ISE is one whose header comment would say -- A pointer to a C string copied from current string. -- Useful only for interfacing with C software. -- Note: the function allocates a new C string for its result; -- use `free' from POINTER to de-allocate it. This assumes that POINTER (in reality POINTER_REF) has a new procedure `free' which does what the name suggests. The same problem arises for ARRAY. I should note that this point is not a matter of preference, but of impossibility. Apart from the view that we have now that `to_pointer' is basically wrong, we see absolutely no way that ISE Eiffel could ever implement it as currently specified. I would like to remove `to_pointer' from vintage 95, and have a discussion on this topic at the Santa Barbara meeting about what to do for 96. Thanks for responding quickly as to whether it is OK to remove it for now. Best regards, -- BM
