libftdi Archives

Subject: Re: Feature Request: Identify LibFTDI Device Strings

From: Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Cc: Karl Semich <0xloem@xxxxxxxxx>
Date: Sun, 2 May 2021 09:51:08 +0200
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+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Current Thread