Linux Programming Discussions

[Trevor Saunders]

Hi,

On Tue, Aug 31, 2010 at 06:37:54PM -0700, Shane W wrote:
> The other issue I see is that sizeof(buff) may or may not
> be the expected return.
> 
> char buff[1024];
> sizeof(buff) = 1024
> char *buff;
> buff = malloc(1024);
> sizeof(buff) = 4 or 8 depending

another good point.

> 
> So I would rework this entire function using poll with a
> timeout rather than read which could block indefinitely and
> a well defined io mechanism.

I don't think there is anything necessarily wrong with using blocking
io.

Trev

> 
> Shane
> On Tue, Aug 31, 2010 at 04:31:05PM -0400, Trevor Saunders wrote:
> > Hi,
> > 
> > > { /*Receive incoming serial data.*/
> > >  STOP=FALSE;                                         
> > > res = 0; /*eventually shows where buffer ends*/
> > > sleep(1);
> > > /*Force a wait to cause receive buffer to stabilize.*/
> > >         while (STOP==FALSE) {       /* loop for input */                      
> > >   
> > >           res = read(fd,buf,sizeof(buf));   /* returns after sizeof(buf) chars have been inputed or timeoutt */ 
> > >   
> > >   
> > > STOP=TRUE;                                         
> > >         }                                                                     
> > >           buf[res]=NULL;               /* so we can printf... */                 
> > 
> > that looks suspect to me, I forget what the spec says NULL means in that
> > case, but I'd use '\0' or just 0 instead, but what you do may work.  I
> > also suspect that if read reads sizeof(buf) bytes and then you set
> > buf[sizeof(buf)] = 0 you will possibly touch memory that isn't yours.
> > 
> > Trev
> > 
> > 
> > > /*That makes sure there is a null to form a strint.*/
> > > /*printf("%s\n", buf);                                       */
> > > return;
> > > } /*Receive incoming serial data.*/
> > > 
> > > 	The only thing I can adjust in the port setup is a
> > > variable that is either kept at 0 so it will time out if no
> > > characters are received at all or to, say, 1024 or whatever the
> > > buffer is defined as. This really doesn't effect the issue but
> > > if set to > 0, the timeout never happens until at least one
> > > character is received.
> > > 
> > > 	Here is the initialization routine. Hardware flow
> > > control is not an option as the receiver does not recognize
> > > RTS/CTS. 
> > > 
> > > #include "headers.h"
> > > #include "defs.h"
> > > #include "externs.h"
> > >   
> > >   
> > > void portinit()
> > >       {                                                                       
> > >         struct termios oldtio,newtio;                                         
> > >   
> > >         fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY );                           
> > >   
> > >         if (fd <0) {perror(MODEMDEVICE); exit(-1); }                          
> > >   
> > >         tcgetattr(fd,&oldtio); /* save current port settings */               
> > > 
> > > /*Clear everything about that port.*/
> > >         bzero(&newtio, sizeof(newtio));                                       
> > >   
> > >         newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD;           
> > >   
> > >         newtio.c_iflag = IGNPAR | ICRNL;
> > >   
> > >         newtio.c_oflag &= ~OPOST;
> > >   
> > >   
> > >         /* set input mode (non-canonical, no echo,...) */                     
> > >   
> > >         newtio.c_lflag = 0;                                                   
> > >   
> > >         newtio.c_cc[VTIME]    = 20;   /* inter-character timer .1 seconds/tick */       
> > >         newtio.c_cc[VMIN] = 0; /*Blocks until VMIN chars or timeout.*/ 
> > >                                                                               
> > >   
> > >         tcflush(fd, TCIFLUSH);                                                
> > >   
> > >         tcsetattr(fd,TCSANOW,&newtio);                                        
> > >   
> > > return;
> > >       }                                                                       
> > > 
> > > I have tried tcflush at the end of a receive with absolutely no
> > > effect on anything.
> > > Shane W writes:
> > > > Hmm, reading from the ttySx device should never give
> > > > duplicatedcharacters so it sounds like something is up with
> > > > your buffer. I wouldn't zero it out but just keep note of
> > > > the number of bytes read and when to stop. Also, after your
> > > > first read returns, don't sleep but rather call poll() on
> > > > the device which will return when there is data ready to be
> > > > read.
> > > 
> > > 	Yes. It is like it is already ready to receive data too
> > > early.
> > > 
> > > 	The hardware is a USB-based 8-port adaptor which behaves
> > > quite normally when using Kermit or other serial routines.
> > > 
> > > 	Thanks.
> > > 
> > > _______________________________________________
> > > Blinux-list mailing list
> > > Blinux-list at redhat.com
> > > https://www.redhat.com/mailman/listinfo/blinux-list
> 
> 
> 
> > _______________________________________________
> > Blinux-list mailing list
> > Blinux-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/blinux-list
> 
> _______________________________________________
> Blinux-list mailing list
> Blinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/blinux-list/attachments/20100831/f38510da/attachment.sig>