0

Because FILE struct is depended on implementation, is there any fail-proof way to resolve FILE "object" to the path of the file it was create with?

keycattie
  • 1
  • 1
  • 3
    No. (This space intentionally left blank) – n. m. could be an AI Jul 20 '20 at 06:05
  • 1
    In general, on Linux (and similar) you may be able to convert FILE* to fd using a the `fileno` call, and then use the answer from here (https://stackoverflow.com/questions/1188757/retrieve-filename-from-file-descriptor-in-c). Fail-proof way? No. – Boris Lipschitz Jul 20 '20 at 06:13
  • 1
    Normally you don't need this anyway. Your program is in charge and so you know which fle you have opened in the first place. What is your use case? – Jabberwocky Jul 20 '20 at 06:19
  • @Jabberwocky in my case i should always check the data im working with. i have an object container, which could be dumped to file. this container has the path string to the file inside, but as a fail-proof i was planning on checking if the file path it has matches the one that is tied to the FILE "object" – keycattie Jul 20 '20 at 06:59
  • 1
    @keycattie: I really do not understand what you actually need.. You want to transform a FILE into a path, but why? What is the context / need? You are normally the one providing the path, not wondering about it. – virolino Jul 20 '20 at 06:59
  • @virolino the part of my reasoning in the comment above your one. but what i want to add to that is that i do not `fclose()` every time i finish working with the `FILE` "object" – keycattie Jul 20 '20 at 07:03
  • @keycattie I think your "fail proof" conecpt here is pointless. _You_ `fopen`ed the file (hopefully) including error checks. Once the file is open, it is open and you don't need to do any more checks to verify the file you opened is _actually_ the file you opened. – Jabberwocky Jul 20 '20 at 07:04
  • @Jabberwocky as long as the pointer to `FILE` can be overwritten with anything else (and in my case that could happen) there is a possibility of my further code to mess up badly. which i was trying to eliminate... – keycattie Jul 20 '20 at 07:09
  • 1
    @keycattie if someone overwrites the area pointed to by a FILE pointer or the file pointer itself, you're in the area of undefined bahaviour and anything can happen anyway, so your check would be really pointless. Even if there was a standard function like `const char *fgetfilename(FILE *file)`, calling this function would result in undefined behaviour if you call it with an invalid or corrupted `FILE` pointer. – Jabberwocky Jul 20 '20 at 07:15
  • 1
    @keycattie: as @ Jabberwocky said, if the FILE structure gets overwritten, then you have much bigger problems to care about. Maybe a full review (including static analysis) is required for your project. – virolino Jul 20 '20 at 08:45

1 Answers1

0

It seems it is either hard due to FILE structure being implementation dependent, or a sign of improperly designed code. As it stands now, stdlib does not provide any way of checking this exact thing. There are ways to check file handles, but those are system dependent and are not practical.

keycattie
  • 1
  • 1