Post by thread:CCS C Compiler GETS() function doesn't work !

Darren Logan wrote: > var = GETC works ok but not GETS(). > Instead, GETS() seems to hang the PIC. It's gets(), surely? If it is the ANSI C function, it is defined as using getc() until it receives an end of line marker. Are you sending characters followed by a carriage return? -- James Cameron (spam_OUTcameronTakeThisOuTstl.dec.com) OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH, COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers, Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control, Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband. "Specialisation is for insects." -- Robert Heinlein.

I had a look through the examples and could not find gets() used anywhere, infact the only reference I can find to gets() is in the book???? If you have a look at GET_STRING() in the input.c file this uses the getc() (ANSI standard) routine. Jason {Quote hidden}>Darren Logan wrote: >> var = GETC works ok but not GETS(). >> Instead, GETS() seems to hang the PIC. > >It's gets(), surely? If it is the ANSI C function, it is defined as >using getc() until it receives an end of line marker. Are you sending >characters followed by a carriage return? > >-- >James Cameron (.....cameronKILLspam@spam@stl.dec.com) > >OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH, >COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers, >Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control, >Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband. > >"Specialisation is for insects." -- Robert Heinlein. > >

James Cameron wrote: > It's gets(), surely? If it is the ANSI C function, it is defined as > using getc() until it receives an end of line marker. Are you sending > characters followed by a carriage return? I have no knowledge of this flavor of C, but shouldn't he be sending a NULL (0x0 0) value to terminate an ASCII string? Could that be the problem? Michael ************************************************************************* When the way of the Tao is forgotten, kindness and ethics must be taught. Men must learn to pretend to be wise and good. -- Lao Tzu *************************************************************************

Hello: Speaking from 20 years of C programming experience: gets() reads characters from standard input into the buffer pointed to by its argument, until either a newline or EOF is encountered on the input. The newline (if one was read) is discarded and the string is terminated with a null before gets() returns. The use of gets() is generally frowned upon since you have no control over the storage into the buffer you supply as argument. If you happen to have misguessed the size of the buffer needed, and you attempt to input more characters than will fit in that buffer, well ... let's just say that that is not going to be a good thing. :-) fgets() (if available in the implementation) is generally preferred over gets() since it allows you to specify a maximum number of characters to read (regardless of whether a newline was seen within that amount). Phil Michael J. Ghormley wrote: > > James Cameron wrote: > > > It's gets(), surely? If it is the ANSI C function, it is defined as > > using getc() until it receives an end of line marker. Are you sending > > characters followed by a carriage return? > > I have no knowledge of this flavor of C, but shouldn't he be sending a NULL (0 x00) > value to terminate an ASCII string? Could that be the problem? > > Michael -- Philip Restuccia Senior Principal Software Engineer Periphonics Corporation philip.restucciaKILLspamperi.com

One way around this is to use a home-made routine in place of gets() - (I name that routine Ngets(), myself) that provides a fgets()-like buffer size limit, for safety (Buffer overruns are a good way to kill off Bulletin Board software, to say nothing of embedded systems!) Indeed a very good habit (I've learned to always transmit buffer sizes to "Fill this buffer" type routines - and to always #define ANY buffer size and use that [if not sizeof()] to tell the routine how big a buffer is. Nothing like spending 12 hours debugging a weird crash to find HOW you shot yourself in the foot. Change a buffer size but don't change the size in one call of 72, & you'll hate it <G> It's always far safer to build you own well-behaved tool, than use existing buggy tools in the vain hope that their *known* shortcomings won't bite you, IMHO. YMMV here! Mark "You wouldn't use a screwdriver as a hammer, don't use gets() when you can write Ngets() in 15 minutes tops", .....mwillisKILLspam.....nwlink.com Philip Restuccia wrote: {Quote hidden}> > Hello: > > Speaking from 20 years of C programming experience: gets() reads > characters > from standard input into the buffer pointed to by its argument, until > either > a newline or EOF is encountered on the input. The newline (if one was > read) > is discarded and the string is terminated with a null before gets() > returns. > > The use of gets() is generally frowned upon since you have no control > over > the storage into the buffer you supply as argument. If you happen to > have > misguessed the size of the buffer needed, and you attempt to input more > characters than will fit in that buffer, well ... let's just say that > that > is not going to be a good thing. :-) > > fgets() (if available in the implementation) is generally preferred over > gets() since it allows you to specify a maximum number of characters to > read (regardless of whether a newline was seen within that amount). > > Phil > > Michael J. Ghormley wrote: > > > > James Cameron wrote: > > > > > It's gets(), surely? If it is the ANSI C function, it is defined as > > > using getc() until it receives an end of line marker. Are you sending > > > characters followed by a carriage return? > > > > I have no knowledge of this flavor of C, but shouldn't he be sending a NULL (0x00) > > value to terminate an ASCII string? Could that be the problem? > > > > Michael > > -- > Philip Restuccia > Senior Principal Software Engineer > Periphonics Corporation > EraseMEphilip.restucciaspam_OUTTakeThisOuTperi.com

On Tue, 22 Dec 1998, Michael J. Ghormley wrote: > James Cameron wrote: > > > It's gets(), surely? If it is the ANSI C function, it is defined as > > using getc() until it receives an end of line marker. Are you sending > > characters followed by a carriage return? > > I have no knowledge of this flavor of C, but shouldn't he be sending a > NULL (0x00) value to terminate an ASCII string? Could that be the > problem? gets will insert the NUL (not NULL) itself as per ANSI C, as soon as it sees an end of line character (usually '\n'). It is possible that it sees a '\r' instead. On a PC, pressing the rightmost Enter key should do this (?). Peter

On Tue, 22 Dec 1998, Darren Logan wrote: > I certainly am. > But still no joy. I think that the gets buffer on a PIC is remarkably short, so I'd start by sending no string, just the end of line character, and see what happens. It is also possible that the port setup glitch after PIC reset puts a garbage character or two in the UART and this clogs gets. I would use a small routine to empty the UART receiver buffer several times before calling gets. The procedure is commonly used in hot-plugged async equipment and in micros whose UART state is undetermined at reset (due to hardware or manufacturer bugs). Peter

On Tue, 22 Dec 1998, Darren Logan wrote: > The particular PIC im using does not have a UART. > The bytes are plopped directly into a string. > > Darren Ah ! I had not thought of that. gets() works only with a stream. I doubt that it will work to read a constant table. It is much more likely that a char* pointer pointed to a string declared and initialized as char[] elsewhere will do what you want. I can't imagine why or how someone can use gets() to read a constant string, even if it happens to be in EERAM. In this case I'd just make it an initialized 'volatile char[]'. Is there anything in the compiler manual about gets() use on certain PICs only (as in: PICs with soft or hard UART) ? Maybe some fine print somewhere else ? Peter

On 22 Dec 98, 19:02 Peter L. Peres wrote: > gets will insert the NUL (not NULL) itself as per ANSI C, as soon as it > sees an end of line character (usually '\n'). It is possible that it sees > a '\r' instead. On a PC, pressing the rightmost Enter key should do this > (?). One might try ^J (i.e. Ctrl + J) aka '\n' aka 0x0a aka 10 aka aka LF aka Linefeed, or ^M (i.e. Ctrl + M) aka '\r' aka 0x0d aka 13 aka CR aka Carriage return instead. There is no end of line or "newline" character in ASCII, so CP/M, MSDOS et al use a CR+LF pair for denoting a line separator. C, coming out of the Unix world, uses a single LF for that purpose. C compilers for the MSDOS+Windows world have a "binary" in the open function, which decides whether the library does a LF <-> CR+LF substitution during IO or not, in order to remain source code compatible. When implementing an gets or alike for an embedded system, I'd interpret both CR and LF as "end of line", but would ignore any LF after a CR, for compatibility reasons. I don't know and dont care about gets (who uses gets?). When looking at input.c (recommended as a gets replacement in the manual, if memory serves me right), I notice that Ccs just looks for a simple 13 (== CR == ^M) the get_string function. I guess gets does it no different. -- o ( Wolfgang.Stroblspam_OUTgmd.de (+49 2241) 14-2394 /\ * GMD mbH #include _`\ `_<=== Schloss Birlinghoven, <std.disclaimer> __(_)/_(_)___.-._ 53754 Sankt Augustin, Germany ________________

Hi, CCS says, "This function reads characters into a string ... until RETURN (13) is encountered" Of course, if you types more characters before RETURN than the buffer size, then subsequent variable values will be trashed. I hope this helps. Imre On Tue, 22 Dec 1998, Mark Willis wrote: {Quote hidden}> One way around this is to use a home-made routine in place of gets() - > (I name that routine Ngets(), myself) that provides a fgets()-like > buffer size limit, for safety (Buffer overruns are a good way to kill > off Bulletin Board software, to say nothing of embedded systems!) > Indeed a very good habit (I've learned to always transmit buffer sizes > to "Fill this buffer" type routines - and to always #define ANY buffer > size and use that [if not sizeof()] to tell the routine how big a buffer > is. > > Nothing like spending 12 hours debugging a weird crash to find HOW you > shot yourself in the foot. Change a buffer size but don't change the > size in one call of 72, & you'll hate it <G> > > It's always far safer to build you own well-behaved tool, than use > existing buggy tools in the vain hope that their *known* shortcomings > won't bite you, IMHO. YMMV here! > > Mark "You wouldn't use a screwdriver as a hammer, don't use gets() > when you can write Ngets() in 15 minutes tops", @spam@mwillisKILLspamnwlink.com > > Philip Restuccia wrote: > > > > Hello: > > > > Speaking from 20 years of C programming experience: gets() reads > > characters > > from standard input into the buffer pointed to by its argument, until > > either > > a newline or EOF is encountered on the input. The newline (if one was > > read) > > is discarded and the string is terminated with a null before gets() > > returns. > > > > The use of gets() is generally frowned upon since you have no control > > over > > the storage into the buffer you supply as argument. If you happen to > > have > > misguessed the size of the buffer needed, and you attempt to input more > > characters than will fit in that buffer, well ... let's just say that > > that > > is not going to be a good thing. :-) > > > > fgets() (if available in the implementation) is generally preferred over > > gets() since it allows you to specify a maximum number of characters to > > read (regardless of whether a newline was seen within that amount). > > > > Phil > > > > Michael J. Ghormley wrote: > > > > > > James Cameron wrote: > > > > > > > It's gets(), surely? If it is the ANSI C function, it is defined as > > > > using getc() until it receives an end of line marker. Are you sending > > > > characters followed by a carriage return? > > > > > > I have no knowledge of this flavor of C, but shouldn't he be sending a NUL L (0x00) {Quote hidden}> > > value to terminate an ASCII string? Could that be the problem? > > > > > > Michael > > > > -- > > Philip Restuccia > > Senior Principal Software Engineer > > Periphonics Corporation > > KILLspamphilip.restucciaKILLspamperi.com > >