Possible fcntl doc glitch #15024
Comments
From @jimavThis is a bug report for perl from jim.avera@gmail.com, perlfunc for fcntl starts with the following example: use Fcntl; What is "$packed_return_buffer" ? It is not explained, and I suspect $flags = fcntl(REMOTE, F_GETFL, 0) or die...; which passes zero for the third argument. Flags: Site configuration information for perl 5.20.2: Configured by Debian Project at Tue Mar 3 11:42:20 UTC 2015. Summary of my perl5 (revision 5 version 20 subversion 2) configuration: Locally applied patches: @INC for perl 5.20.2: Environment for perl 5.20.2: |
From @maukeAm 03.11.2015 um 03:43 schrieb (via RT):
No, perldoc -f fcntl starts with: | Implements the fcntl(2) function. You'll probably have to say Following that (and immediately preceding your code) it says: | Argument processing and value returned work just like ioctl below. For and indeed perldoc -f ioctl explains the semantics of the SCALAR argument. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Tue Nov 03 12:23:47 2015, plokinom@gmail.com wrote:
I do think that Jim Avera, the OP, has a point. I rarely say: ##### Much more often I say ##### ... and in the latter case the fact that I am actually paging through pod/perlfunc.pod is not self-evident. If I *am* paging through pod/perlfunc.pod, then the phrase "just like C<ioctl> below" is, strictly speaking, true. That's because the section on 'fcntl' starts at line 2218 of pod/perlfunc.pod (blead), whereas the section on 'ioctl' starts at line 3087. But that's the exception. If I'm only saying 'perldoc -f fcntl' I have no reliable way of knowing where "below" is. Can anyone suggest wording that avoids this problem? Thank you very much. -- |
From @jimavI still don't understand why the first example in the fcntl POD is, or can be, correct:
The ioctl pod does not explain it. It merely says that the The later example in the fcntl POD is
and it *does* seem to work: Here's what happens using the ioctl-ish example: $ perl -MData::Dumper -MFcntl -we 'my $buf=""; fcntl(STDIN,F_GETFL,$buf); print "buf=", Dumper($buf);' |
From @tonycozOn Mon Nov 02 18:43:26 2015, jim.avera@gmail.com wrote:
Yes, the example is bogus, since F_GETFL ignores the third argument. There are three cases that matter: - fcntl(2) ignores the third argument (F_GETFL) - fcntl(2) accepts an integer (F_SETFL) - fcntl(2) accepts a pointer to a structure (F_SETLK) but none of the examples demonstrate that third case, and the "struct flock" type is kind of under-specified[1] to use for a portable example. Maybe an example specifying it's Linux specific. Tony [1] POSIX only specifies that the flock structure has certain members and doesn't specify their order - it's different between NetBSD and Linux. |
From @wolfsageOn Sun, Nov 8, 2015 at 11:33 PM, Tony Cook via RT
Hrm, I think IPC::Cmd is broken then? # prepare sockets to read from child $flags = 0; $flags = 0; $flags = 0; -- Matthew Horsfall (alh) |
From @tonycozOn Tue Nov 10 05:29:58 2015, alh wrote:
Sorry, I thought I'd replied to this, yes, IPC::Cmd is broken, but since for a socket/pipe only O_NONBLOCK is likely to be set, it turns out to be harmless. It should be fixed though. Tony |
From @tonycozOn Wed Jan 06 20:07:15 2016, tonyc wrote:
Fixed in d5eedef. I've created a pull request against IPC::Cmd at Tony |
|
@tonycoz - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for submitting this report. You have helped make Perl better. Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0 |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#126544 (status was 'resolved')
Searchable as RT126544$
The text was updated successfully, but these errors were encountered: