You are not logged in.
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??
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... ;-)
"The only difference between me and a madman is that I'm not mad."
Salvador Dali (1904-1989)
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.
Just for fun.
I got exactly the same problem and after 4 hours of reading my code, I finally found the problem.
if( sock=accept(server_sock,(struct sockaddr*)&client_add,&len) < 0 )
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.
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...
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
Well, I suppose I shouldn't be too surprised that a Microsoft compiler would violate the standards... But, direct assignment is definitely lower precedence than less-than...