Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use win32 glob implementation on all platforms #18164

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

NattyNarwhal
Copy link
Member

Due to inconsistencies across platforms (see GH-15564), it's probably better to have a consistent glob implementation everywhere. We already have to have one for Win32 (based on the OpenBSD implementation), so we can also use it on Unix too.

Some concerns:

  • Using the system glob implementation isn't wired up yet; just a matter if binding ifdefs and gunk in the build system.
  • HAVE_GLOB is removed from code; should only be used for the previously mentioned system glob implementation if we decide to use that.
  • GLOB_ONLYDIR is a GNU extension, not implemented by the OpenBSD implementation (nor is it by macOS, other BSDs, musl, etc.). However, it's handled by callers due to the fact the GNU implementation is flawed, so we don't need to implement it in the glob implementation, especially if we want to be compatible with non-GNU. We just need to define the flag. This also removes an unused define as well.

This may need an RFC. It may also be prudent to merge GH-17433.

In preparation to make the Win32 reimplementation the standard
cross-platform one. Currently, it doesn't do that and just passes
through the original glob implementation. We could consider also having
an option to use the standard glob for systems that have a sufficient
one.
Kind of broken. We're namespacing the function and struct, but not yet
the GLOB_* defines. There are a lot of places callers check if i.e.
NOMATCH is defined that would likely become redundant.

Currently it also has php_glob and #defines glob php_glob (etc.) - I
suspect doing the opposite and changing the callers would make more
sense, just doing MVP to geet it to build (even if it fails tests).
Have not tested yet. the big things are:

- Should be invisible to userland PHP code.
- A lot of :%s/GLOB_/PHP_GLOB_/g; the diff can be noisy as a result,
  especially in comments.
- Prefixes everything with PHP_ to avoid conflicts with system glob in
  case it gets included transitively.
- A lot of weird shared definitions that were sprawled out to other
  headers are now included in php_glob.h.
- A lot of (but not yet all cases) of HAVE_GLOB are removed, since we
  can always fall back to php_glob.
- Using the system glob is not wired up yet; it'll need more shim
  ifdefs for each flag type than just glob_t/glob/globfree defs.
This is a GNU extension, but we don't need to implement it, as the GNU
implementation is flawed enough that callers have to manually filter it
anyways; just provide a stub definition for the constant.

We could consideer implementing this properly later. For now, fixes the
basic glob constant tests.
We now always have a glob implementation that works. HAVE_GLOB should
only be used to check if we have a system implementation, for if we
decide to wrap the system implementation instead.
@NattyNarwhal
Copy link
Member Author

cc @Girgias

@Girgias
Copy link
Member

Girgias commented Mar 27, 2025

This is basically just moving stuff from Win32/ to main/ and defining the symbols as php right? This looks rather sensible just on its own, not sure if it needs an RFC, but maybe a quick discussion on internals is sufficient? I would imagine most people would agree that having the same behaviour regardless of platform is a win.

@NattyNarwhal
Copy link
Member Author

This is basically just moving stuff from Win32/ to main/ and defining the symbols as php right?

Correct, plus some cleanup of redundant definitions.

This looks rather sensible just on its own, not sure if it needs an RFC, but maybe a quick discussion on internals is sufficient? I would imagine most people would agree that having the same behaviour regardless of platform is a win.

This sounds good, I'll start there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants