Discussion:
Feature Request: Identify LibFTDI Device Strings
Thomas Jarosch
2021-05-02 07:51:08 UTC
Permalink
Hi Karl,

You wrote on Wed, Feb 10, 2021 at 05:21:37PM -0500:
[ftdi_usb_open_string()]
It seems ftdi_usb_open_string() returns -12 if the ftdi pointer is
null, _before_ it validates the string, and contrariwise dereferences
the passed pointer if it is not null, preventing a user from fudging
validation with a fake pointer.
It would be great if this check returning -12 were simply moved after
the basic string validation, so the -11 return value could be used
even without an ftdi context. This could probably be done robustly by
handing off the port opening to the other functions that don't take
strings, after the string has been parsed.
It would alternatively be great if the string validation code were
moved into a new public function like ftdi_valid_usb_string(const char
*), so that what the user is accomplishing can be detected without
setting up all the infrastructure.
I've looked at ftdi_usb_open_string() and I think swapping the handling
of the -12 <-> -11 error checks is just half the job.
All other string validations might need the ftdi context pointer.

I would be ok with having a new "ftdi_valid_usb_string(const char *)"
function and we could also call it from ftdi_usb_open_string(),
it's not a performance critical path and people don't have thousands
of FTDI devices attached to one computer ;)

Do you want to cook something up?

Cheers,
Thomas

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com
Karl Semich
2021-05-02 19:49:47 UTC
Permalink
Post by Thomas Jarosch
It would be great if this check returning -12 were simply moved after
the basic string validation, so the -11 return value could be used
even without an ftdi context. This could probably be done robustly by
handing off the port opening to the other functions that don't take
strings, after the string has been parsed.
It would alternatively be great if the string validation code were
moved into a new public function like ftdi_valid_usb_string(const char
*), so that what the user is accomplishing can be detected without
setting up all the infrastructure.
I've looked at ftdi_usb_open_string() and I think swapping the handling
of the -12 <-> -11 error checks is just half the job.
All other string validations might need the ftdi context pointer.
I would be ok with having a new "ftdi_valid_usb_string(const char *)"
function and we could also call it from ftdi_usb_open_string(),
it's not a performance critical path and people don't have thousands
of FTDI devices attached to one computer ;)
Do you want to cook something up?
Thanks so much for your reply. I didn't know whether this project was
still active.

I ended up finding another solution, but if I get back into that work at
some point maybe I can look into making a patch.
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+***@developer.intra2net.com
Loading...