Skip to content

perlfunc - warn of platform specific quirks in gethost* and co. #23472

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

Open
wants to merge 1 commit into
base: blead
Choose a base branch
from

Conversation

richardleach
Copy link
Contributor

This is a small commit in response to #23463 warning that platform-specific
quirks could be encountered with these functions. (The specific case
encountered is given as an example, but the warning is meant to be
generic to this bit of perlfunc.)

A bigger revision of that pod may be warranted, but this PR won't be it.


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

pod/perlfunc.pod Outdated
various get routines are as follows:
These routines are the same as their counterparts in the system
C library. This means that platform-specific quirks may be
encountered. (For example, C<gethostbyname(undef)> will fail on
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should say C<gethostbyname("")> because gethostbyname stringifies its argument. Also, shouldn't this be added to perlport instead?

Currently the only note there is for Irix 5. A Win32 note would make sense to me.

  • gethostbyname

    (Irix 5) gethostbyname('localhost') does not work everywhere: you may have to use gethostbyname('127.0.0.1').

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my $r = gethostbyname(undef); can not be written in the C lang.

P5P decides what ASCII string becomes in C lang. That choice was not made by some unnamed OS vendor.

I would've filed my bug ticket exactly as I did if this disclaimer was only found inside perlport.pod.

The tradition of any PP keyword that matches a C lang function from POSIX's libc, is bug compatible with the libc.so file on the end user's disk, and bug compatible with whatever libc.man.3 says on the end user's filing system, stopped 20-25 years ago.

I remember back in 2005 to ~2012, when PP keywords prinf() and sprintf(), were documented by P5P to be bug compatible with Check your vendor's libc.man.3 file for what this Perl keyword does.

That is obviously a lie for decades, if not since "alpha 5.000_001" or maybe since Perl 2.0.0 or Larry's initial commit.

I'd rather see the disclaimer inside the official documentation for getwhateverbywhatever() than hidden inside perlport where no Linux Perl user or Win32 Perl user will ever see it.

My original bug ticket was complaining, that I wanted retval -1 and PP keyword gethostbyname(undef) did not return -1 when I instructed it to returned -1, per POSIX Perl expectations.

The production code use case for executing gethostbyname(undef); in Perl 5 lang is to execute this noop()

pp_gethostbyname()->win32_gethostbyname()->_tailMerge_ws2_32_dll(...)->
    _delayLoadHelper2()-> win32_dot_c_delayHook() -> {
        WSAStartup();
        win32_hook_imported_function_in_module(phModule, pFn, (void*)my_CloseHandle);
   };

from Pure Perl, no .pm files allowed.

But !@#$ gethostbyname(undef) turned out to NOT BE A NOOP() expression!!!!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is any of this related to my review comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mauke - thanks, I shortened the perlfunc warning, mentioning perlport, and put the specific example notes in the latter. This seems neater than what I'd originally proposed, short of reworking that whole section of pod. :/

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.

4 participants