Weitao Sun wrote: > Martin Paljak wrote: > >> On 18.03.2009, at 5:00, Weitao Sun wrote: >> >> >>> 4.The user want a second keypair(KEYPAIR_B), so we will alloc a new ID >>> for it. We, again, start from DEFAULT_ID(0x45) to 0xFF, pick a number, >>> because KEYPAIR_A's ID is not DEFAULT_ID(0x45), we pick 0x45 again. >>> >> Quickfix could be to assign the ID like "0x45 + count(existing_keys)" ? >> >> > No, when any key is deleted, things got mass up. > We can't determine paths depend on object IDs, because object ID can be changed by user to arbitrary values. So is to the number of existing keys. According to Murphy's law, when there is possibility user can do wrong, he will. And in this case, it is not actually user's fault.
Could we travel all objects to see whether the new path has already been used? If so, pick another, otherwise we can use it. This policy don't depend on user's behavior. But it involves so many code changing. -- Weitao Sun <wei...@ftsafe.com> EnterSafe division <www.entersafe.com> R&D Dep.,Feitian Technologies Co., Ltd. <www.ftsafe.com> 5th Floor, Building 7A, No.40 Xueyuan Road Haidian District, Beijing, P.R. China, PostCode 100083 TEL: (86)10 62304466 Ext. 585 FAX: (86)10 62304416 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
