printing fcntl( fd, F_GETFL,0 ) return value changes its representation

weinstev has asked for the wisdom of the Perl Monks concerning the following question:

#!/usr/bin/perl -w
use Fcntl;

# Experimenting with fcntl system call

## open this file
open( FH, ">>fcntl.pl" );

$cur_opts = fcntl( FH, &F_GETFL, 0 );
#  The print statement of death....
#  print "cur_opts -> $cur_opts\n";

$rc = fcntl( FH, &F_SETFL, $cur_opts );
# "fixes" The print statement of death...
#$rc = fcntl( FH, &F_SETFL, $cur_opts & 0xffffffff );

print "rc -> $rc\n";

$new_opts = fcntl( FH, &F_GETFL, 0 );
print "new_opts -> $new_opts\n";

if ( $new_opts != $cur_opts ) {
    print "ERROR\n";
} else {
    print "Calling F_SETFL with F_GETGL return value succeeded.\n";
}
print "new_opts -> $new_opts  cur_opts -> $cur_opts\n";
[download]

In trying to verify the proper use of fcntl (so that I can set a socket file descriptor to non-blocking), I stumbled upon the above curiosity. When I run the above code, the output generated is

rc -> 0 but true
new_opts -> 1025
Calling F_SETFL with F_GETGL return value succeeded.
new_opts -> 1025  cur_opts -> 1025
[download]

However, if I un-comment out the "print statement of death" line (see code above), I get the following output:

cur_opts -> 1025
rc -> 0 but true
new_opts -> 8193
ERROR
new_opts -> 8193  cur_opts -> 1025V@S@ÿÿÿÿ0ÿÿÿÿÿÿÿÿHÿÿÿÿ N@
[download]

What I want to know, then, is what crime against nature have I committed by printing out the value of $cur_opts. Or, more importantly, how can I avoid this type of problem in the future? Note that masking off the 32 low order bits in the subsequent F_SETFL call allowed me to include the print line of death. Thanks for your assistance/explanation,
Victor

Edit by tye, add CODE tags, remove BR

Comment on printing fcntl( fd, F_GETFL,0 ) return value changes its representation Select or Download Code

Replies are listed 'Best First'.
Re: printing fcntl( fd, F_GETFL,0 ) return value changes its representation (usage) by tye (Sage) on Jun 06, 2003 at 16:25 UTC
When I do "perldoc -f fcntl" I see: `use Fcntl; fcntl($filehandle, F_GETFL, $packed_return_buffer) or die "can't fcntl F_GETFL: $!";` [download] which shows that F_GETFL "gets" the value into the third argument. I think that when you do: `$cur_opts = fcntl( FH, &F_GETFL, 0 );` [download] Perl passes the address of the constant string, "0", to fcntl(). But fcntl() was expecting the address of a properly sized buffer for it to write the "FL" that you wanted to "GET" into. So fcntl() overwrites the 'constant' string, "0", which is stuff that Perl wasn't expected to be overwritten. The design of fcntl() (Unix design, not Perl design) requires that the caller know what types are argument(s) to pass for each command code and doesn't provie any good ways to check/enforce that. You didn't obey that rule. This corrupted some data and what Perl does after that could be nearly anything. - tye	[reply] [d/l] [select]
Re: Re: printing fcntl( fd, F_GETFL,0 ) return value changes its representation (usage) by weinstev (Initiate) on Jun 06, 2003 at 18:00 UTC
If you look at man 2 fcntl, the actual Unix C function does not require a third argument. However, Fcntl::fcntl does. If you look at perldoc -f ioctl, you will find an example of fcntl using 0 as the third parameter. If you look at my original post, I have verified the validity of the syntax `$flags = fcntl( FH, F_GETFL, 0 ); $rc = fcntl( FH, F_SETFL, $flags );` [download] However, what causes the call to fail is if I print the value returned from the F_GETFL call `$flags = fcntl( FH, F_GETFL, 0 ); print "current flags -> $flags\n"; ## now we've got trouble $rc = fcntl( FH, F_SETFL, $flags );` [download] I am not sure why the ioctl documentation and fcntl documentation are out of synch, but the third argument is NOT required by the Unix C function; I have verified that, in the absence of the print statement, my call syntax is not the issue. Thanks for your response, feel free to correct my logic as necessary. Victor	[reply] [d/l] [select]
Re^3: printing fcntl( fd, F_GETFL,0 ) return value changes its representation (usage) by tye (Sage) on Jun 06, 2003 at 19:35 UTC
I never said your syntax was incorrect. You should not be passing `0` as the third argument for `F_GETFL`. Update: isotope mentioned to me that newer versions of the ioctl POD do exactly as you have done. Well, I get suspicious of an examples in ioclt POD that are for the wrong function, and it didn't look like anyone was trying what I suggested. So I tried the different methods of doing F_GETFL (one from fcntl, one from ioctl) on an ancient Unix system that was handy and the one from ioctl was correct (on that Unix system), but it also didn't exhibit the original problems in this thread. So I suspect that the usage of F_GETFL varies between versions of Unix. In any case, one or both of the fcntl/ioctl PODs could use some updates when we figure this out. (: - tye	[reply] [d/l] [select]