Attention is currently required from: Felix Singer, Thomas Heijligen.

View Change

1 comment:

• Patchset:

  • Patch Set #1:

    Then also see CB:67886 ;) […]

    Thomas, thanks for the suggestion. We're not sure how to integrate it, though. Could you please elaborate a bit more on it? Thanks.

    The ultimate goal is to have something like this:

    ```
    int my_prog_init_new(prog_cfg *cfg)
    {
    	int ret = 0;
    	const struct my_prog_params params = my_prog_get_params(&ret, cfg);
    	if (!ret)
    		ret = my_prog_init(&params);
    	
    	my_prog_release_params(&params);
    	return ret;
    }
    ```

    Where parsing programmer parameters from the string is separate from actually initializing the programmer itself. The "release_params" function provides a way to free all temporary strings needed for programmer init (e.g. serial numbers and the like). This approach will introduce a bit of overhead (`strdup()` plus `free()`) for strings in programmer params that are stored into the "master" data (e.g. device paths), but it ensures that the dynamic memory used by programmers is under their own control and can't be invalidated by the caller after programmer init.

To view, visit change 67908. To unsubscribe, or for help writing mail filters, visit settings.