"samdb_msg_add_string" cleanup

[Matthias Dieter Wallnöfer]

Hi Andrew,

Andrew Bartlett wrote:
> It would seem to me that if we had:
>
> int ldb_msg_add_dup_string(struct ldb_message *msg,
> 		   	   const char *attr_name, const char *str)
> {
> 	struct ldb_val val;
>
> 	val.length = strlen(str);
> 	if (val.length == 0) {
>
> 		/* allow empty strings as non-existent attributes */
> 		return LDB_SUCCESS;
> 	}
> 	val.data = talloc_strdup(msg, str);
> 	if (val.data) {
> 	        return LDB_ERR_OPERATIONAL;
> 	}
>
> 	return ldb_msg_add_steal_value(msg, attr_name,&val, NULL);
> }
>
> Then this would be equivalent in almost all cases, and an improvement in
> talloc hierarchy.  We should consider if we want to add another LDB API
> however, as it may be better just to change samdb_msg_add_string to have
> this behaviour.
>    
this could be a good idea. I think that it's really better to move this 
"samdb_msg_add_string" call into the main LDB - since it isn't really 
SAMDB specific.
> However, even this would need to be handled carefully, and I'm thinking
> that it might be better to leave cleanup patches such as this alone for
> a little while, until we sort out the issues with the other recent
> changes you have made.
>
> Please don't make a 'simple' translation to ldb_msg_add_string(), each
> case does need to be looked at carefully.
>    
Yes, okay. Should I propose some patches for review?

Cheers,
Matthias