Mark do_open(), do_openn() as internal, not public

[khwilliamson]

These undocumented functions have exactly 0 uses on CPAN.

do_open() is mentioned in 7 distributions. In all cases it is to #undef the macro name because it was polluting the distro's name space which has its own function named do_open().

• This set of changes does not require a perldelta entry.

[tonycoz]

do_open() is used by the standard typemap, some CPAN modules use do_openn() File-Map, mod_perl, Linux-CDROM though I don't know how current any of those are.

[khwilliamson]

cpan grep shows no uses of do_openn()

https://grep.metacpan.org/search?q=do_openn&qft=&qd=&qifl=ppport.h

And yet it does get called, as you said, in File::Map
https://metacpan.org/release/LEONT/File-Map-0.71/source/lib/File/Map.xs

Am I doing something wrong, or is metacpan search buggy?

[Leont]

Am I doing something wrong, or is metacpan search buggy?

If you select *.xs, *.c as the file extensions, four dists will show up: https://grep.metacpan.org/search?q=do_openn&qft=*.xs%2C+*.c&qd=&qifl=

[khwilliamson]

That sounds like a bug. I want to do an unrestricted search, and yet it doesn't find it.

[tonycoz]

I have a local (bare) clone of https://github.com/metacpan/metacpan-cpan-extracted.git and I git grep that instead of using grep.metacpan.org (it's a lot faster, but 4.4GB disk space).

[Leont]

That sounds like a bug. I want to do an unrestricted search, and yet it doesn't find it.

I can't reproduce it anymore, but I did see it right when you posted. I guess it was just glitching or something? I've seen some other weird results today as well.

[khwilliamson]

I have been getting randomly wrong results with the search, so will open a ticket against that.

[khwilliamson]

It turns out that do_open is marked as binary-compatibility only, so, presuming that is correct, there is no need to mark that as internal.

And do_open6 and 'do_open_raw` are marked as experimental. Should that be removed from one or both of them?