>
> set_blocking(s);
> if( !is_blocking(s))
> fail();
>
>
>
> and it's failing. Any hints?

Check the return value from the fcntl systemcalls.
they could be -1 ...

HTH,
AvK

Michael wrote:
# I have 3 functions, as follows (sans fluff such as error handling, et
# al)
#
#
# is_blocking(int s)
# {
# int flags = ::fcntl(s, F_GETFL, 0);
# if( flags == (flags | O_NONBLOCK) )

return !(flags & O_NONBLOCK)

# }
#
# set_nonblocking(int s)
# {
# int flags = ::fcntl(s, F_GETFL, 0);
# ::fcntl(s, F_SETFL, flags | O_NONBLOCK);
# }
#
# set_blocking(int s)
# {
# int flags = ::fcntl(s, F_GETFL, 0);
# ::fcntl(s, F_SETFL, flags & (~O_NONBLOCK));
# }
#
#
# I have a test that does basically the following:
#
# set_blocking(s);
# if( !is_blocking(s))
# fail();
#
#
#
# and it's failing. Any hints?
#
#
#

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I hope it feels so good to be right. There's nothing more
exhilarating pointing out the shortcomings of others, is there?

On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:

> Michael wrote:
> # I have 3 functions, as follows (sans fluff such as error handling, et
> # al)
> #
> #
> # is_blocking(int s)
> # {
> # int flags = ::fcntl(s, F_GETFL, 0);
> # if( flags == (flags | O_NONBLOCK) )
>
>

Yes, that looked pretty unreadable.
I would even prefer(since I don't trust C++/True/false):
return (flags & O_NONBLOCK) ? False : True;

(I would probably prefer the function name "is_nonblocking()" )
BTW function names that start with "is" are reserved in C. Don't know
about C++.

AvK

moi writes:

> On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:
>
>> Michael wrote:
>> # I have 3 functions, as follows (sans fluff such as error handling, et
>> # al)
>> #
>> #
>> # is_blocking(int s)
>> # {
>> # int flags = ::fcntl(s, F_GETFL, 0);
>> # if( flags == (flags | O_NONBLOCK) )
>>
>>
>
> Yes, that looked pretty unreadable.
> I would even prefer(since I don't trust C++/True/false):
> return (flags & O_NONBLOCK) ? False : True;
>
> (I would probably prefer the function name "is_nonblocking()" )
> BTW function names that start with "is" are reserved in C. Don't know
> about C++.

In C, only identifiers starting "is" and followed by a lowercase
letter are reserved. is_xxx is fine, as is isXXX.

--
Ben.

On Aug 19, 11:20 pm, moi wrote:
> On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:
> > Michael wrote:
> > # I have 3 functions, as follows (sans fluff such as error handling, et
> > # al)
> > #
> > #
> > # is_blocking(int s)
> > # {
> > # int flags = ::fcntl(s, F_GETFL, 0);
> > # if( flags == (flags | O_NONBLOCK) )
>
> Yes, that looked pretty unreadable.
> I would even prefer(since I don't trust C++/True/false):
> return (flags & O_NONBLOCK) ? False : True;
>
> (I would probably prefer the function name "is_nonblocking()" )
> BTW function names that start with "is" are reserved in C. Don't know
> about C++.
>
> AvK


mol:

* I stated in my original posting that the code did not include error
handling.

* In the event that my test in is_blocking would produce an incorrect
result, I would appreciate the feedback. However, from your reply I'm
going to make 2 separate guesses. 1. It's functionally correct and 2.
you managed to read it.

* I'm working in C++ and this is sitting in a namespace. The use of
the scope resolution operator makes it apparent that it's C++ code. I
never mentioned any namespace, so I can almost forgive you that,
except for the fact that I never mentioned it because it has
absolutely nothing to do with the problem.


If you'd like to discuss the stylistic advantages/disadvantages to the
approaches that I've taken, please start another line of discussion.


SM Ryan:

That was how I had originally codified it, but I changed it to the
explicit true/false return in an attempt to illuminate all the
corners. It was basically a last ditch effort to make sure some weird
craziness wasn't going on.

On Sun, 19 Aug 2007 17:30:28 -0700, Michael wrote:

> On Aug 19, 11:20 pm, moi wrote:
>> On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:
>> > Michael wrote:
>> > # I have 3 functions, as follows (sans fluff such as error handling, et
>> > # al)

> mol:
>
> * I stated in my original posting that the code did not include error
> handling.

My bad. Sorry about that.

>
> * In the event that my test in is_blocking would produce an incorrect
> result, I would appreciate the feedback. However, from your reply I'm
> going to make 2 separate guesses. 1. It's functionally correct and 2.
> you managed to read it.

And 3. Since it is functionally correct, it can be tested separately (and
probably work as you expect it to. Ergo 4. You probably snipped too much ? )

>
> * I'm working in C++ and this is sitting in a namespace. The use of the
> scope resolution operator makes it apparent that it's C++ code. I never
> mentioned any namespace, so I can almost forgive you that, except for
> the fact that I never mentioned it because it has absolutely nothing to
> do with the problem.

Yes. Does errno sit in a global-scope namespace, too ?

>
>
> If you'd like to discuss the stylistic advantages/disadvantages to the
> approaches that I've taken, please start another line of discussion.
>

This is usenet, remember ?

> SM Ryan:
>
> That was how I had originally codified it, but I changed it to the
> explicit true/false return in an attempt to illuminate all the corners.
> It was basically a last ditch effort to make sure some weird craziness
> wasn't going on.

That is what most people would do, I suppose.

AvK

On Aug 20, 7:41 am, moi wrote:
> On Sun, 19 Aug 2007 17:30:28 -0700, Michael wrote:
> > On Aug 19, 11:20 pm, moi wrote:
> >> On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:
> >> > Michael wrote:
> >> > # I have 3 functions, as follows (sans fluff such as error handling, et
> >> > # al)
> > mol:
>
> > * I stated in my original posting that the code did not include error
> > handling.
>
> My bad. Sorry about that.
>
>
>
> > * In the event that my test in is_blocking would produce an incorrect
> > result, I would appreciate the feedback. However, from your reply I'm
> > going to make 2 separate guesses. 1. It's functionally correct and 2.
> > you managed to read it.
>
> And 3. Since it is functionally correct, it can be tested separately (and
> probably work as you expect it to. Ergo 4. You probably snipped too much ? )

is_blocking is passing it's tests. You were the one who chose to
worry about that particular function, not I.

I'm not that experienced with unix style file descriptors, hence my
mailing of this group. Am I doing something with my calls to fcntl
that would cause it to not block? Under what circumstances will fcntl
not change a descriptor to a blocking status? (in reference to both a
file descriptor and a socket descriptor).

The calls to fcntl are *not* giving errors.

>
>
>
> > * I'm working in C++ and this is sitting in a namespace. The use of the
> > scope resolution operator makes it apparent that it's C++ code. I never
> > mentioned any namespace, so I can almost forgive you that, except for
> > the fact that I never mentioned it because it has absolutely nothing to
> > do with the problem.
>
> Yes. Does errno sit in a global-scope namespace, too ?

We both know the answer to that, what is it you're trying to lead to?


>
>
>
> > If you'd like to discuss the stylistic advantages/disadvantages to the
> > approaches that I've taken, please start another line of discussion.
>
> This is usenet, remember ?
>
> > SM Ryan:
>
> > That was how I had originally codified it, but I changed it to the
> > explicit true/false return in an attempt to illuminate all the corners.
> > It was basically a last ditch effort to make sure some weird craziness
> > wasn't going on.
>
> That is what most people would do, I suppose.
>
> AvK

I found the problem. I had gotten my bit manipulations backwards,
unsetting the O_NONBLOCK flag instead of setting it. The example code
I gave previously was what I thought I did, but apparently it wasn't
what I actually did.

Thanks for the help guys, hopefully I won't discover any more silly
errors.