Marcel Holtmann wrote: >Hi Pedro, > > >>In the application I am developing, I want to log some information about >>Bluetooth devices, pretty much like "sdptool browse" and "hcitool info" >>do. In the code of these applications, there are calls to some library >>functions like hci_dflagstostr(), hci_lmtostr()... that create a string >>with information about the device (flags, features, etc.). >> >>The problem with these functions is that they call malloc(), expecting >>the caller to call free(). The problem with that is that this approach >>is not save, as it is not guaranteed that calling malloc() in a library >>function and free() in the main program works. In fact, I have seen a >>segmentation fault doing that. >> > >explain why this is not safe. > I am not an expert in these issues, but I have read many times that there is no guarantee that the malloc/free implementation is the same in the main program and in the libraries. This is due to how the different modules are compiled: compiler version, compile flags, etc. But, as I said, I am not 100% sure. I am quite sure that I have read this for Windows, but maybe (probably) Linux is different. > >>AFAIK, there are two alternatives: either the library functions expect a >>buffer (and its size) to be filled or malloc() and free() are both done >>within the library, which means creating a new library function call for >>freeing buffers allocated with malloc(). Are any of this alternatives >>implemented or on the roadmap? What workaround do you suggest? >> > >We can do that, but it is not on my roadmap. Send my patches for it and >I will review them. The easiest way to do it (and to continue with the actual API without modifications) would be to have a function call like: void hci_str_free(char *str) { free(str); } So after a call to hci_dflagstostr() (for example), the resulting pointer should be freed with hci_str_free(). In any case, there is one exception: hci_dtypetostr(); it returns a pointer to static data. Cheers, Pedro