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
