Hi Neil.

14-May-04 12:38:00, Neil Heller wrote to Jasen Betts


NH>> In the function msg_receive, fd is a socket connected to a
NH>> remote  Internet client. 

NH>> What is wrong with msg_receive? Suggest a fix.

JB>> are you #including io.h ( for read())

NH>>    #define MAXVALS 65536
NH>>    typedef struct _msg_t {
NH>>      unsigned int num;
NH>>      unsigned int values[MAXVALS];
NH>>    } msg_t;

JB>> how wide is your size_t  (16 bit compilers won't like that but they
JB>> should complain...)

 NH> IIRC the application was for a 16-bit embedded system.  I remember 
 NH> something about 16-bit systems have a real limit vis array access of
 NH> 65520 bytes.  This would be 131,072 bytes.  Is that what you were 
 NH> meaning?

65520 (64K less 16 bytes) looks like a malloc limit, which is certainly
worth consideration :)

I while ago I was playiung with a large amound of data in an array in
turbo-c's (16 bit) huge memory model but I don't recall what hoops I had to
jump throught to get it to work. (and I've misplaced the source)

NH>>    int msg_receive(int fd, msg_t *m)
NH>>    {
NH>>      size_t sz = sizeof(unsigned int);
NH>>      assert(m);
NH>>      if( read(fd, (void *)&m->num, sz) < sz)

JB>> what byte-order are you (and the sender) using

 NH> Why cast the number as a pointer to void?

It wasn't my cast, it's not a number.
 read() expects a char* pointer, the expression
"&m->num" is of type int*.

 NH> Considering that read is unbuffered, would the last statement of
 NH> msg_received overrun any 16-bit buffer?

that's not what unbuffered means.

unbuffered in that context meant that the a READ call results in a request
to the OS for only that many bytes.

a call to fread or getc will usually reesult in more than the requested
number fo bytes being requested from the OS the extras are buffered, or
held in reserve for subsequent reads call.

as to overruns if the code compiles without warnings it should work.

 -=> Bye <=-

---