You are not logged in.
Pages: 1
I'm trying to create a super-simple client-server. When I call 'accept' in the server it returns a zero. Formally it isn't an error, but when I later calls 'recv' with the accept return value as it's first parametr, it returns -1 and errno=38, which means 'not a socket descriptor'. What is the problem and how can I fix it??
Offline
More input... need more input
Please post more details, the problematic parts of your code, the OS and other information you might find important would be enough to help you out with this
Offline
By any chance are you closing stdin...?
Its just a thought but... if you are then that means file handle ( number ) 0 becomes available for use... so um... it would be perfectly legitimate for a call to accept to return a value of 0...
If that isn't what is occurring... then I would put forth that your computer is possessed by evil spirits and the appropriate action(s) should be taken immediately...
Darn - it seems part of my message was cut off somehow... continuing... lol
Ok... so that is a likely cause and though its something simple its easy to miss...
If it isn't that...
Are you doing anything strange like creating a listening socket... then forking off children and having more than one of the children doing accept calls on it? Now, that shouldn't be returning you a 0 on error and in fact on the systems that don't like it, it should cause a fault of some sort... but if you have that fault handled ( unintentionally ) by a custom signal handler that doesn't do anything the 'result' of accept could appear to be 0...
Hope that helps... ;-)
Michael
"The only difference between me and a madman is that I'm not mad."
Salvador Dali (1904-1989)
Offline
Michael,
Thanks for your timely and creative reply. Turns out that that pesky "missing parens problem" inside a rather deep "if" question is still lurking. A careful inspection of the expression (after about four hours of being sure that I messed something up with the sockets interface) found the problem. Basic stuff.
I'm all set, thanks.
Bob
Offline
Hello,
Just for fun.
I got exactly the same problem and after 4 hours of reading my code, I finally found the problem.
I coded
if( sock=accept(server_sock,(struct sockaddr*)&client_add,&len) < 0 )
instead of
if( (sock=accept(server_sock,(struct sockaddr*)&client_add,&len)) < 0 )
As the < has a higher priority with my compiler (g++) sock was always 0 instead of having the good file descriptor number returned by accept.
Grrrr !
Yep, that type of bug bites a lot of people...
It's not just that compiler, BTW... Any compiler that conforms to the C/C++ standards will behave the same... But, if you're lucky, your compiler might warn you about such shady-looking assignments within if statements... GCC (and presumably g++ as well) will do so if you compile with "-Wall", which is always a good idea...
Offline
Hello,
In fact, I ported a small server which running well on windows. It seems that Visual C++ and gcc does not compile this ambiguous code in the same manner.
You're right, comipiling the buggy code with -Wall option gives:
main.cpp:52: warning: suggest parentheses around assignment used as truth value
Pages: 1