Quoth John Forte on Tue, Aug 14, 2007 at 05:02:41PM -0700: > This sounds like a reset to the collection with each call to > scf_transaction_property_change such that when adding a new value to the > property I should be iterating through the existing list of values > calling scf_entry_add_value for each?
Right. > I seem to be running into some difficulty when adding more than one. > Trying to commit the transaction results in an invalid argument error on > commit. By any chance, is there a restriction on using the same > allocated scf_value_t in the multiple scf_entry_add_value calls, i.e. > Does the scf_entry_add_value add the address of 'value' or a copy? It > seems like if I change or destroy the value once it is set, prior to > commit, the commit will fail with the invalid argument error. Must I > call scf_entry_add_value with a different scf_value_t for each > scf_entry_add_value within a single transaction? You are correct. The idea was that we want you to be in control of memory allocation, so we don't want to allocate new memory in order to copy the value over into. So you have to allocate all of the scf_value_t's and scf_transaction_entry_t's yourself. This is a pain. It would be easier for you to just tell us "I'm going to make a transaction with N values", and we allocate enough memory for you. I'll try to fix this in the Enhanced SMF Profiles interfaces. > Additionally, is there any max list length that I need be aware of? How > about max astring/ustring size? I believe scf_value_t's are limited to 8Ki or so. I don't think there is a limit to the number of values in the collection, inherently, but I do believe that they all have to fit into the transaction request, which is gathered into an alloca() block. Which I think means that if your collection is too big, your client will segfault. David
