Printable View
As I mentioned, I didn't think that was the issue, I am just issuing you a warning in more human terms than your compiler issues warnings in. Because you will listen to us where your compiler fails to get through to you. And yeah your closes are all out of whack. And more importantly, your code doesn't look like it uses any of the C stream functionality at all... well except for fclose()........
Even if it's UNLIKELY, being correct is important when it comes to computers.Quote:
Originally Posted by MK27
--
Mats
that fclose is on the steam which read the file into a buffer. It's irrelevant to all the socket stuff. The buffer already contains the file, then gets transmitted.Quote:
Originally Posted by robwhit
Here is the deal.... fclose() will clean up after the FILE * structure produced by fdopen(). close() will just close the descriptor you have opened. This is where Mats is free to jump in with a correction, but you should only call fclose().
Well, for argument's sake I tried it, and it didn't matter. Just to clarify, tho -- you do understand thatQuote:
Originally Posted by master5001
fclose(fstRO);
refers to
FILE *fstRO = fopen(argv[1], "rb")
and NOT
if ((sstOUT=fdopen(OUT,"w"))==NULL) perror("fdopen");
And: what file structure created by fdopen? The problem is that fdopen isn't creating anything, it returns NULL on an apparently bad descriptor, but the next command
write(OUT,buffer,bytes);
succeeds (OUT being the "Bad descriptor").
once you fdopen() you should be using fwrite() anyway. But I somehow doubt that is the real problem.
I'm taking this to heart because I obviously want your advice. What do you mean by "your code doesn't look like it uses any of the C stream functionality at all":Quote:
Originally Posted by master5001
Is all the C stream functionality I could muster, except for the final buffer write andCode:FILE *fstRO = fopen(argv[1], "rb"), * sstOUT;
FILE *fstW = fopen("/root/test/image.jpg", "wb");
struct sockaddr addr;
if (fstRO == NULL) {
puts("valid filename required");
return -1;}
stat(argv[1],&finfo);
bytes=finfo.st_size;
buffer=malloc(bytes);
buffer2=malloc(bytes);
printf("%d\n",bytes);
fread(buffer,bytes,1,fstRO);
fclose(fstRO);
which is just there to demonstrate that it doesn't work.Code:if ((sstOUT=fdopen(OUT,"w"))==NULL) perror("fdopen");
And what, pray tell, are my closes "out of whack" with?
ps. I didn't use fwrite because -- once again -- fdopen (there is only one) FAILED. The write is to the socket descriptor, not a stream.
pps. I just noticed that cboard will not accept "* sst" without the space, and instead replaced it with ........ perhaps I am haunted today.
Ah ok. Well is fdopen() failed because of an invalid descriptor, then anything done with that descriptor should be equally ineffective, right? So why are you getting an invalid socket to begin with becomes the question. I don't believe you can use bind with AF_LOCAL. I am going to see what I can find. Double check the socket you are making to make sure it is even valid.
Ok yeah I am really starting to think the problem is with how you create your socket to begin with. I am not as familiar with AF_LOCAL to be trouble shooting your code by hand at this point. So I did read some manual pages to see what that address family does support, and it looks like there are a few things that it doesn't necessarily allow. You are probably doing something outside of the scope of that kind of socket.
AHHHRGGHHH!!!! How many times do I have to point out that the fd is obviously valid because the file transfer DOES happen.Quote:
Originally Posted by master5001
w/r/t bind, I'll check that out -- all the examples I found were INET, but nowhere in the GNU documentation does it say "don't bind local sockets".
[moment later] no, I guess you don't have to bind them, but it still works out the same way
I couldn't find any formal documentation behind binding local sockets. Ok so it is valid (obviously) then perhaps fdopen() simply doesn't support that kind of socket. Ok so lets just remove fdopen() from the picture, does your code work if you comment out those lines of code?
But according to RobSeace, adminstrator of the unix socket forum (a little undercrowded, surprise) on developerweb, "the fdopen() trick SHOULD work fine, if you really wanted to go that route...But, it's really not necessary"
Which I didn't want to, I started out doing it because the file transferred on the descriptor with read/write is/was bum, etc. And again, according to all the sources (eg. Codeplug) that is the usual way to go and it should work.
Maybe it's my kernel;)
I am thinking it is an issue of the type of connection you are creating not being supported by fdopen(). And yes, conventional wisdom suggests that fdopen() should work. However, evidence seems to suggest otherwise (which is a kick in the teeth when these things happen).
Try making a non-local connection and seeing if fdopen() will work. Why not rebuild your kernel to support the support fdopen() with AF_LOCAL.
Probably I should try this first.Quote:
Originally Posted by master5001
Just google your kernel version, OS, and the problem. Usually someone out there will tell you exactly which flags will need to be set for this. Unless you like rooting through your kernel's source code. Which is fine if you do, you are a better man than I if so.