Add new comment

It looks like their are quite

It looks like their are quite a few references to file path throughout the code despite having the file stream.

Long story short, will I be able to create a data stream that does not have access to a true file path? I should be able to get a file name, but unfortunately that's the extent. If it's not possible the rest of this post is irrelevant, just analysis of the impact of file path in the code. If it is possible, if you don't mind elaborating on the impact it would help me greatly. Thanks.

1) I noted a few line directives from dcraw.c. Do I need to be concerned about its use of file path or just within libraw?

LibRaw_abstract_datastream::subfile_open(const char *fn)
2) I only note this used in a parse_external_jpeg() which seems to be a hack to get metadata. It appears to be a warning at worse on a filename issue. Correct?
3) What is the significance of this function? It appears to open any file really, but has a thread lock. Correct?

#define ifname ((char*)libraw_internal_data.internal_data.input->fname())
4) This seems to be more of a concern, there are 17 references in dcraw_common, a lot in the same LibRaw_abstract_datastream::subfile_open(const char *fn) function and some related to minolta. There are many more references to its own similar 'ifname' in dcraw.c itself if I need to be concerned with that?