So to summarize, the only reason the lend/borrow variants exist is to allow optimization of code so that it avoids copying long DNs. Tweo examples of safe cases:
1) You are making a blocking down-call => it is safe to lend to the down-call because the instance that is lended will not be deallocated while you are blocked. 2) You are inside a callback that got an instance as callback argument => it is safe to borrow the string inside the callback because the callback arguments con only be de-allocated after you return from the callback. /AndersBj Anders Bjornerstedt wrote: > Hi Praveen, > A few comments below. > > praveen malviya wrote: > >> Hi Minh, >> >> I saw the test and the way long DN is being used in the API. >> I tried to modified that in one way for short DN(below is the >> patch/diff on top this patch). >> >> But I have certain doubts: >> In case ldap_name is less the 256, it can be set directly using >> saAisNameLend(),below diff, and ntfsubscribe successfully receives it. >> > The reason it is called xxxLend() and xxxBorrow() is to signify that you > can only use a lended/borrowed value when the original still exists. > The the programmer coding a lend/borrow must do so responsibly. > > So if the original (the instance that is lended, ot hte instance that is > borrowed from) goes out of scope or risks being deallocated while > the lended/borrowed value is still being used, then you must of course > *copy* the string and of course make it clear who owns (and deallocates) > that copy. > You should follow this reasoning always and assume that the string can > be longer than 256. > >> This goes by the description of saAisNameLend() as in such a case the >> contents of the string is copied into the SaNameT type and can be read >> in a >> backwards compatible way by legacy applications that do not support >> the extended SaNameT format". >> Because of this I was able to set ldap_name directly using >> saAisNameLend(). >> >> But in case ldap_name is greater than 256 then saAisNameLend() >> description says "if length of the string >> is greater than or equal to SA_MAX_UNEXTENDED_NAME_LENGTH, no copying >> is performed. Instead, a reference to the original >> string is stored in the SaNameT type." >> > In this case you should create a new SaNameT instance, not use > saAisNameLend() to lend the string to the instance. > I suggest not writing code checking for length here. You would just be > optimizing usage of "short" strings which is not > worth it. > >> So for long DN the same does not work and ntfsubscribe receives the >> garbage value because the buffer contains the reference and not the >> original value. >> But above description we know what saAisNanmeLend() has done. So I >> think we need to decide: this should be considered internally in the >> Send () API or let it to user to >> set the longDn as in the example test case. For notificationObject and >> NotifyingObject we are setting longDn by directly using saAisNameLend(). >> > in any context where you are transferring an SaNameT from one owner to > another owner and the receiver could be using that value *after* > the original SaNameT value has been deallocated, then you need to copy, > i.e. create a new independent value owned by the receiver. > > /AndersBj > >> What do you think? >> >> Thanks, >> Praveen >> > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Opensaf-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensaf-devel > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
