Hi Thomas, 2009/7/27 Thomas Jarosch <[email protected]>: > Maybe we should prefix the function name with "ftdi_" to indicate > this belongs to libftdi. Something like ftdi_usb_close() ;-)
Except this is not a function that anything outside of ftdi.c should ever see. Naming is entirely up to you, as long as the basic operation stays I'll be very happy. > What about adding the "if (ftdi->usb_dev != NULL)" > check to the already existing ftdi_usb_close()? I forgot about that, and there is a problem still there. Just call ftdi_usb_close(...) twice on the same handle to see it in action. Both functions are still needed since there are places where a usb close is called, but where control can get back to a calling application. Imagine: - app calls ftdi lib function, * function fails in ftdi lib, usb_close called, error flags returned - app decised to recover from error and calls ftdi_usb_close * segfault. There is also some overlap with deinit, but I can't think of a nice way to resolve it at the moment. Ideally there would only be one path to obtaining an ftdi handle, and only one path for invalidating it Attached (sorry about the garbled patch, I'm only new to git) is a new patch with an extra check, let me know how that works for you. Cheers, Nath. -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
0001-PATCH-Fix-for-double-free-and-segfault-after-close.patch
Description: Binary data
