Bodo Moeller wrote: > Ideally this would be true, but in practice various applications do > access some fields directly. > > The big change to stop that would be to move all the struct details > completely out of the externally visible header files. Of course, that > change too would be rather painful for such applications.
Which applications do you know about doing this ? are they public ? Shouldn't there be something to take from that, if the existing APIs do not provide enough feature coverage shouldn't those users be encouraged to document their "use case" and provide application code "test cases" where information is needed to allow somebody to understand and implement suitable API. The suggestion I have thrown in, will not alter the meaning of the lowest 2 bits of ssl_st.new_session (between older versions of OpenSSL and future versions of OpenSSL). So it would be possible for a user doing this to write code that works for all versions of OpenSSL alike (all versions that have ssl_st.new_session at least). The suggestion I have thrown in will not affect anybody who is using OpenSSL in a portable way (I think we should have more consideration for those users, than those who access internal structures directly). The choice: * Enlarge the structure and cause breakage for all users of OpenSSL that allocate a storage in the application for struct ssl_st (affecting both: the group that uses the documented APIs and the group that uses undocumented direct access to internal structure) * Modify the purpose of some of the bits in ssl_st.new_session. This change only affects the group of users that access internal structures directly and only if they happen to access the "new_session" member itself. However the proposed way forward will allow them to fix their code in such a way that same code will work with version 1.0.0 at runtime alike. I see the "modify the purpose" option as affecting the least number of users. Darryl ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
