5 ms·

The old code checks for the filepath to be present before attempting to dlopen it. The new way requires you to dlopen the path. This is very meh because dlopen

by zaarn 6y ago

The old code checks for the filepath to be present before attempting to dlopen it. The new way requires you to dlopen the path. This is very meh because dlopen already executes code from the library, so if you didn't want that, good luck. (glibc and some other core libs like openssl like to detect plugins by probing the paths for libs and only loading them when necessary)

afandian 6y ago
Yeah. So I understand it has been considered best practice to check the file before opening it? Does that mean we can assume that most well-written programs will follow the pattern and break on mac os? I would have thought that even if Apple did make this change they could trap the fopen or whatever and return something useful based on a heuristic? It wouldn't be the first time that they put exceptions and heuristics in for software compatibility.
- chrisseaton 6y ago
  > So I understand it has been considered best practice to check the file before opening it? Check it... for what?
  - coldtea 6y ago
    For presence...
    - chrisseaton 6y ago
      Why do you need to separately check for presence before you use dlopen? If it's not there dlopen will give you a nice error message - no need to check yourself. Are you currently checking files are there before you dlopen them? How do you avoid a race between the stat and the dlopen? What happens if the file is removed between them? Seems broken and you shouldn't be doing this in the first place.
      - zaarn 6y ago
        It is usually unlikely that a file will be removed between stat and dlopen, such errors occur rarely. Even more rarely when the file happens to be a systems lib or plugin lib. Some errors occur rarely enough that it isn't worth worrying about.
- unilynx 6y ago
  It has never been good practice to check before open - open first, then check. And if you're creating a file, use exclusive mode, don't check first. You're opening yourself up to a lot of race conditions otherwise, and this has been the source of many security vulnerabilities

by zaarn 6y ago

afandian 6y ago

Yeah. So I understand it has been considered best practice to check the file before opening it? Does that mean we can assume that most well-written programs will follow the pattern and break on mac os? I would have thought that even if Apple did make this change they could trap the fopen or whatever and return something useful based on a heuristic? It wouldn't be the first time that they put exceptions and heuristics in for software compatibility.

chrisseaton 6y ago
> So I understand it has been considered best practice to check the file before opening it? Check it... for what?
- coldtea 6y ago
  For presence...
  - chrisseaton 6y ago
    Why do you need to separately check for presence before you use dlopen? If it's not there dlopen will give you a nice error message - no need to check yourself. Are you currently checking files are there before you dlopen them? How do you avoid a race between the stat and the dlopen? What happens if the file is removed between them? Seems broken and you shouldn't be doing this in the first place.
    - zaarn 6y ago
      It is usually unlikely that a file will be removed between stat and dlopen, such errors occur rarely. Even more rarely when the file happens to be a systems lib or plugin lib. Some errors occur rarely enough that it isn't worth worrying about.
unilynx 6y ago
It has never been good practice to check before open - open first, then check. And if you're creating a file, use exclusive mode, don't check first. You're opening yourself up to a lot of race conditions otherwise, and this has been the source of many security vulnerabilities