Thread: What mean filedescriptor error-codes?

Hi,

Originally Posted by matsp

And you should DEFINITELY close the file after it's been opened.

So do I: syscall(__NR_close,fd);

Originally Posted by Salem

> for ( buffer_len=1; buffer[buffer_len] != '\0'; buffer_len++);

As said this is strlen without including string.h .

Originally Posted by matsp

read doesn't append a \0, so it's wrong to use strlen() to go looking for it.
Since read() returns a result (which you're ignoring), perhaps you could pick that up and use that to determine how much to write.
[..]
If it's a text file and there's more than 100 bytes in the file, it will fail to have a zero at the end. [And of course, the string could be EMPTY, in whcih case starting at 1 could give the wrong result.

I can't follow that? I created a 182kb textfile and have resized my buffers and everything works fine. What do you mean with there's not always \0 representing the eof? What else? Or how could I achivie this by using syscalls? You say read is giving something back? I mean how works strlen:

Code:

static inline size_t strlen(const char * s)
{
int d0;
register int __res;
__asm__ __volatile__(
        "repne\n\t"
        "scasb\n\t"
        "notl %0\n\t"
        "decl %0"
        :"=c" (__res), "=&D" (d0)
        :"1" (s),"a" (0), "0" (0xffffffffu)
        :"memory");
return __res;
}

I don't understand this asm+C mixture totally but the line starting with :"1" looks for me like checking for wheter \a or \0 depending on if it's a string or a file?


@ the why-question for this all: I'm just playing around I found a paper explaining how to use syscalls in kernelmodules, so I wanted to learn how to invoke them from C and just wanted to play around a bit with them. Next to the fact that calling the syscall directly should be faster or?

greets

Okay I did now like suggested and a few other things, so I think now there shouldn't be any errors:

Code:

#include </usr/include/linux/unistd.h>
#include </usr/include/asm/stat.h>

int main(int argc, char *argv[1]) {

        int fd,len;
        struct stat mystat ;
        
        fd = syscall(__NR_open,argv[1],00,04000) ;
        if (fd==-1) {
                syscall(__NR_write,1,"No such file\n",13);
                return 1;
                         }

        syscall(__NR_fstat,fd,&mystat);
        char buffer[mystat.st_size];

        len = syscall(__NR_read,fd,buffer,mystat.st_size);
        syscall(__NR_close,fd);
        syscall(__NR_write,1,buffer,len);

        return 0;
}

thanks for all youre help!

Originally Posted by Salem

> char buffer[mystat.st_size];
Variable length arrays, and declarations in the middle of statements are both outside the scope of C89.

Really? I thought this would be a good way of reading files with unknown length.

Okay I got now behind, that I have to use gcc -pedantic to get these kind of warnings you are telling about.

Originally Posted by Salem

Also, if you have a file of many MB in size, you've just blown away the stack.

I didn't realize that because I thought there's a max size arrays could be and after that it would simply stop allocating memmory.

But what is then the best or better correct way of reading a file with unknown size? Getting its size and reading then block for block?

greets

Yes the while loop is a good solution and works really well:

Code:

#include </usr/include/linux/unistd.h>

#define BUFSIZE 4092

int main(int argc, char *argv[1]) {
         
   
        char buffer[BUFSIZE];
        int fd,len;

        if (argc!=2) {
                syscall(__NR_write,1,"Usage: macro [filename]\n",24);
                return 0;
                             } 
        
        fd = syscall(__NR_open,argv[1],00,04000) ;

        if (fd==-1) {
                syscall(__NR_write,1,"No such file\n",13);
                return 0;
                           }

        while ((len=syscall(__NR_read,fd,buffer,BUFSIZE))>0) { syscall(__NR_write,1,buffer,len);}
 
        syscall(__NR_close,fd);
      

        return 0;
}

Hi okay I did a ~60MB Zip-file for this test now.

Code:

time cat ind.zip
[..]
real   2m31.340s
user   0m00.000s
sys    2m30.089s

time ./macro ind.zip
[..]
real   2m34.212s
user   0m00.004s
sys    2m33.358s

But I dunno how relyable this test is. Not pretty much or what do you think?

I took here the best clocktick for 1000 tries, one time for sys_write and the other time for printf. I think this is a better method than the above:

Code:

#include </usr/include/linux/unistd.h>
#include <stdio.h>
#include </usr/src/linux-headers-2.6.20-16/include/asm-i386/msr.h>

int main(void) {

   unsigned long ini, end, now, best, tsc;
   int i;
   char buffer[4];

#define measure_time(code) \
   for (i = 0; i < 10000; i++) { \
      rdtscl(ini); \
         code; \
      rdtscl(end); \
      now = end - ini; \
      if (now < best) best = now; \
   }

   /* time rdtsc (i.e. no code) */
   best = ~0;
   measure_time( 0 );
   tsc = best;

   /* time an empty read() */
   best = ~0;
  // measure_time(  syscall(4,1,"test1\n",6) );
   measure_time(  printf("test2\n") );

   /* report data */
   printf("rdtsc: %li ticks\nsyscall():%liticks\n",
   tsc, best-tsc);
      
   return 0;
}

Now I get for the syscall_write:

rdtsc: 192 ticks
syscall():3396ticks

and for printf:

rdtsc: 192 ticks
syscall():4092ticks

Which is an expected result because calling syscalls should of course be faster than calling the libC first which then calls the syscalls.

fputs doesn't seem much faster than printf. It's best result was 4032ticks over 1000 tries..

I'll redo the time-test this night with closed X-server and no network-connection to bypass any irregularities.