Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #104752 > unrolled thread

writing a c program to substitute text

Back to article view | Back to comp.lang.c

Contents

  writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-02-26 04:14 -0800
    Re: writing a c program to substitute text fir <profesor.fir@gmail.com> - 2017-02-26 04:55 -0800
    Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-26 14:28 +0100
      Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-02-27 03:58 -0800
        Re: writing a c program to substitute text Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 13:11 +0000
          Re: writing a c program to substitute text BartC <bc@freeuk.com> - 2017-02-27 13:33 +0000
            Re: writing a c program to substitute text scott@slp53.sl.home (Scott Lurndal) - 2017-02-27 17:12 +0000
              Re: writing a c program to substitute text BartC <bc@freeuk.com> - 2017-02-27 17:59 +0000
                Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 19:05 +0100
                Re: writing a c program to substitute text scott@slp53.sl.home (Scott Lurndal) - 2017-02-27 18:37 +0000
                  Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-27 11:40 -0800
          Re: writing a c program to substitute text Manfred <noname@invalid.add> - 2017-02-27 16:03 +0100
          Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-03-01 05:33 -0800
            Re: writing a c program to substitute text "D. Aaron Sawyer" <aaron@110.net> - 2017-03-01 10:32 -0400
              Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-03-01 06:59 -0800
                Re: writing a c program to substitute text Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-01 15:24 +0000
                  Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-03-02 01:47 -0800
                    Re: writing a c program to substitute text Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-02 11:05 +0000
        Re: writing a c program to substitute text jt@toerring.de (Jens Thoms Toerring) - 2017-02-27 13:33 +0000
          Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-27 09:10 -0800
            Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 19:07 +0100
              Re: writing a c program to substitute text jt@toerring.de (Jens Thoms Toerring) - 2017-02-27 18:23 +0000
        Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 14:46 +0100
          Re: writing a c program to substitute text James Kuyper <jameskuyper@verizon.net> - 2017-02-27 09:27 -0500
            Re: writing a c program to substitute text GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-27 15:28 +0100
              Re: writing a c program to substitute text James Kuyper <jameskuyper@verizon.net> - 2017-02-27 09:38 -0500
            Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 15:44 +0100
              Re: writing a c program to substitute text James Kuyper <jameskuyper@verizon.net> - 2017-02-27 10:36 -0500
              Re: writing a c program to substitute text Anglican <h.toms@qmul.ac.uk> - 2017-02-27 15:50 +0000
                Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 17:13 +0100
                Re: writing a c program to substitute text Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-27 16:30 -0800
            Re: writing a c program to substitute text fir <profesor.fir@gmail.com> - 2017-02-27 07:08 -0800
              Re: writing a c program to substitute text fir <profesor.fir@gmail.com> - 2017-02-27 07:20 -0800
                Re: writing a c program to substitute text fir <profesor.fir@gmail.com> - 2017-02-27 07:24 -0800
          Re: writing a c program to substitute text Manfred <noname@invalid.add> - 2017-02-27 16:00 +0100
          Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-27 09:22 -0800
            Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 19:11 +0100
        Re: writing a c program to substitute text John Bode <jfbode1029@gmail.com> - 2017-02-28 15:41 -0800
          solved Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-03-02 01:25 -0800
            Re: solved Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-03-02 11:28 +0100
            Re: solved Re: writing a c program to substitute text Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-02 10:54 +0000
              Re: solved Re: writing a c program to substitute text Manfred <noname@invalid.add> - 2017-03-02 15:28 +0100
                Re: solved Re: writing a c program to substitute text Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-02 14:51 +0000
              Re: solved Re: writing a c program to substitute text John Bode <jfbode1029@gmail.com> - 2017-03-02 14:18 -0800
                Re: solved Re: writing a c program to substitute text Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-02 23:55 +0000
                  Re: solved Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-03-14 18:32 -0700
          Re: writing a c program to substitute text Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-17 07:04 -0700
      Re: writing a c program to substitute text jladasky@itu.edu - 2017-02-27 13:48 -0800
        Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-02-27 14:16 -0800
          Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-28 08:47 +0100
            Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-02-28 01:59 -0800
              Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-28 11:39 +0100
              Re: writing a c program to substitute text Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 12:03 +0000
                Re: writing a c program to substitute text BartC <bc@freeuk.com> - 2017-02-28 13:33 +0000
                  Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-28 14:43 +0100
                    Re: writing a c program to substitute text BartC <bc@freeuk.com> - 2017-02-28 13:59 +0000
                      Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-03-01 04:26 -0800
        Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 23:29 +0100
        Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-27 15:10 -0800
    Re: writing a c program to substitute text Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-26 06:42 -0800
      Re: writing a c program to substitute text Richard Heathfield <rjh@cpax.org.uk> - 2017-02-26 16:54 +0000
        [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-02-27 00:56 +0800
      Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-26 13:36 -0800
        Re: writing a c program to substitute text Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-26 14:53 -0800
          Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 00:53 +0100
            Re: writing a c program to substitute text Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-26 17:30 -0800
              Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-26 17:44 -0800
              Re: writing a c program to substitute text Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 01:46 +0000
                Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 09:29 +0100
                  Re: writing a c program to substitute text Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-27 02:12 -0800
                    Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-27 13:11 +0100
      Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-02-27 04:41 -0800
        Re: writing a c program to substitute text Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-27 05:04 -0800
          Re: writing a c program to substitute text Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 13:25 +0000
          Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-27 09:56 -0800
    Re: writing a c program to substitute text "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-02-27 01:00 +0800
    Re: writing a c program to substitute text "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-26 18:55 -0500
      Re: writing a c program to substitute text fred flintstone <fred@server.invalid> - 2017-02-28 04:20 -0800
        Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-28 14:38 +0100
          Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-28 08:33 -0800
            Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-28 19:38 +0100
              Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-28 11:40 -0800
                Re: writing a c program to substitute text David Brown <david.brown@hesbynett.no> - 2017-02-28 21:03 +0100
              Re: gcc optimization levels Noob <root@127.0.0.1> - 2017-02-28 22:55 +0100
        Re: writing a c program to substitute text "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-28 11:43 -0500
        Re: writing a c program to substitute text Keith Thompson <kst-u@mib.org> - 2017-02-28 08:46 -0800

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#105317 — Re: solved Re: writing a c program to substitute text

fred flintstone <fred@server.invalid> writes:
<snip>

There's a bug in the code, so I'll mention a couple of other things that
are not very important since I posting about something that does matter.

<snip>
> /**
>  * Read the next token from the input stream.  In this program,
>  * tokens are either sequences of alphanumeric characters, or individual
>  * non-alphanumeric characters.  Both are saved as strings to buf.
>  *
>  * For example, the input ">>text3.txt" would be tokenized as ">", ">",
>  * "text3", ".", "txt".
>  */
> int getNextSym( FILE *stream, char **buf, size_t *bufsize )

I would consider returning the number of characters read here.  It's
always a shame to return 0/1 when you have a potentially useful
alternative.  You might not need it now, but getNextSym is a potentially
reusable function.

> {
>   size_t charsRead = 0;
>   int c;
>
>   while ( ( c = fgetc( stream ) ) != EOF )
>   {
>     if ( !isalpha( c ) && !isdigit( c ) )

You can use isalnum here.

>     {
>       if ( charsRead > 0 )
>       {
>         /**
>          * If we've read a sequence of alphanumeric characters,
>          * we *don't* want this non-alphanumeric character to be
>          * part of the string (IOW, we treat all non-alphanumerics
>          * as string delimiters).  Push the current character back
>          * on to the input stream, terminate the buffer, and return.
>          */
>         ungetc( c, stream );
>         (*buf)[charsRead] = 0;
>         return 1;
>       }
>       else
>       {
>         /**
>          * All non-alphanumeric characters are returned in their own
>          * 1-character strings.
>          */
>         (*buf)[0] = c;
>         (*buf)[1] = 0;
>         return 1;
>       }
>     }
>     else
>     {
>       /**
>        * Current character is alphanumeric, so we want to
>        * append it to the buffer, extending the buffer if
>        * necessary.
>        */
>       if ( charsRead < *bufsize || expand( buf, bufsize ) )

I think you need <= here or you can overflow the buffer when it gets
zero terminated.

>       {
>         (*buf)[charsRead++] = c;
>       }
>       else if ( charsRead == *bufsize )
>       {
>         /**
>          * Buffer expansion failed; push the latest character back on
>          * to the input stream, terminate the buffer, and return a failure
>          * code.  It's up to the caller to decide what to do next.
>          */
>         ungetc( c, stream );
>         (*buf)[charsRead-1] = 0;
>         return 0;
>       }
>     }
>   }
>   if ( charsRead > 0 )
>   {
>     /**
>      * We hit EOF while reading an alphanumeric sequence; terminate
>      * the buffer.
>      */
>     (*buf)[charsRead] = 0;
>     return 1;
>   }
>
>   return 0;
> }
>
> /**
>  * Parse the sequence number out of the file name.  This assumes the
>  * file name is of the form "toolchain<N>.sh".
>  */
> int getOrdinal( const char *filename )
> {
>   int ord;
>   if ( sscanf( filename, "toolchain%d.sh", &ord ) == 1 )

I think I'd relax the requirement that it must be "toolchain" but that's
a small matter.  You could make the output file have the same pattern as
the input file but with the number incremented.

>     return ord;
>
>   return -1;

I like to use a conditional expression in such cases

  return sscanf(filename, "toolchain%d.sh", &ord) == 1 ? ord : -1;

> }

<snip>
>   size_t bufsize = 80; // initial buffer size
>   char *buffer = malloc( bufsize );

You should really check the buffer != 0 here.

What I do in these cases in to start by setting buffer = 0 and
bufsize = 0 so the first character triggers and expand operation.  You
need to make the expand work correctly with a zero size so you can do

  new_size = size * 2 + 80;

or

  new_size = size ? 80 : size * 2;

but that avoids duplicating allocation code and checks.

>   /**
>    * Meat of the program - read the next symbol from the input file.
>    * If it matches our search symbol, write the replacement symbol
>    * to the output file - otherwise, copy the input symbol to the
>    * output file.  **/
>   while ( getNextSym( input, &buffer, &bufsize ) )
>   {
>     if ( strcmp( buffer, sym1 ) == 0 )
>       fprintf( output, "%s", sym2 );
>     else
>       fprintf( output, "%s", buffer );
>   }

Again I favour conditional expressions for cases like this:

  fputs(strcmp( buffer, sym1 ) == 0 ? sym2 : buffer, output);

>   free( buffer );
>   fclose( input );
>   fclose( output );
>
>   return 0;
> }

<snip>
Only the buffer overrun is really significant.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#105320 — Re: solved Re: writing a c program to substitute text

On 3/2/2017 11:54 AM, Ben Bacarisse wrote:
> fred flintstone <fred@server.invalid> writes:
> <snip>
>
> There's a bug in the code, so I'll mention a couple of other things that
> are not very important since I posting about something that does matter.
>
<snip>
>>     {
>>       /**
>>        * Current character is alphanumeric, so we want to
>>        * append it to the buffer, extending the buffer if
>>        * necessary.
>>        */
>>       if ( charsRead < *bufsize || expand( buf, bufsize ) )
>
> I think you need <= here or you can overflow the buffer when it gets
> zero terminated.
Hm. You are right about overflow, but I think the solution should be:
        if ( (charsRead+1) < *bufsize || expand( buf, bufsize ) )

>
>>       {
>>         (*buf)[charsRead++] = c;
>>       }
>>       else if ( charsRead == *bufsize )
>>       {
>>         /**
>>          * Buffer expansion failed; push the latest character back on
>>          * to the input stream, terminate the buffer, and return a failure
>>          * code.  It's up to the caller to decide what to do next.
>>          */
>>         ungetc( c, stream );
>>         (*buf)[charsRead-1] = 0;
>>         return 0;
>>       }
>>     }
>>   }
>>   if ( charsRead > 0 )
>>   {
>>     /**
>>      * We hit EOF while reading an alphanumeric sequence; terminate
>>      * the buffer.
>>      */
>>     (*buf)[charsRead] = 0;
>>     return 1;
>>   }
>>
>>   return 0;
>> }
<snip>

[toc] | [prev] | [next] | [standalone]

#105321 — Re: solved Re: writing a c program to substitute text

Manfred <noname@invalid.add> writes:

> On 3/2/2017 11:54 AM, Ben Bacarisse wrote:
>> fred flintstone <fred@server.invalid> writes:
>> <snip>
>>
>> There's a bug in the code, so I'll mention a couple of other things that
>> are not very important since I posting about something that does matter.
>>
> <snip>
>>>     {
>>>       /**
>>>        * Current character is alphanumeric, so we want to
>>>        * append it to the buffer, extending the buffer if
>>>        * necessary.
>>>        */
>>>       if ( charsRead < *bufsize || expand( buf, bufsize ) )
>>
>> I think you need <= here or you can overflow the buffer when it gets
>> zero terminated.
> Hm. You are right about overflow, but I think the solution should be:
>        if ( (charsRead+1) < *bufsize || expand( buf, bufsize ) )

Yes, thanks, wasn't thinking.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#105336 — Re: solved Re: writing a c program to substitute text

On Thursday, March 2, 2017 at 4:54:26 AM UTC-6, Ben Bacarisse wrote:
> fred flintstone <fred@server.invalid> writes:
> <snip>
> 
> There's a bug in the code, so I'll mention a couple of other things that
> are not very important since I posting about something that does matter.
> 

In my defense, I tossed this off in about 15 minutes without putting too
much thought into it, so I'm not surprised there are problems.  Like I
said, this ain't professional-quality code.

> <snip>
> > /**
> >  * Read the next token from the input stream.  In this program,
> >  * tokens are either sequences of alphanumeric characters, or individual
> >  * non-alphanumeric characters.  Both are saved as strings to buf.
> >  *
> >  * For example, the input ">>text3.txt" would be tokenized as ">", ">",
> >  * "text3", ".", "txt".
> >  */
> > int getNextSym( FILE *stream, char **buf, size_t *bufsize )
> 
> I would consider returning the number of characters read here.  It's
> always a shame to return 0/1 when you have a potentially useful
> alternative.  You might not need it now, but getNextSym is a potentially
> reusable function.
> 

Wouldn't that be covered by calling strlen on the target buffer?

> > {
> >   size_t charsRead = 0;
> >   int c;
> >
> >   while ( ( c = fgetc( stream ) ) != EOF )
> >   {
> >     if ( !isalpha( c ) && !isdigit( c ) )
> 
> You can use isalnum here.

Derp.  Forgot about that.  

> 
> >     {
> >       if ( charsRead > 0 )
> >       {
> >         /**
> >          * If we've read a sequence of alphanumeric characters,
> >          * we *don't* want this non-alphanumeric character to be
> >          * part of the string (IOW, we treat all non-alphanumerics
> >          * as string delimiters).  Push the current character back
> >          * on to the input stream, terminate the buffer, and return.
> >          */
> >         ungetc( c, stream );
> >         (*buf)[charsRead] = 0;
> >         return 1;
> >       }
> >       else
> >       {
> >         /**
> >          * All non-alphanumeric characters are returned in their own
> >          * 1-character strings.
> >          */
> >         (*buf)[0] = c;
> >         (*buf)[1] = 0;
> >         return 1;
> >       }
> >     }
> >     else
> >     {
> >       /**
> >        * Current character is alphanumeric, so we want to
> >        * append it to the buffer, extending the buffer if
> >        * necessary.
> >        */
> >       if ( charsRead < *bufsize || expand( buf, bufsize ) )
> 
> I think you need <= here or you can overflow the buffer when it gets
> zero terminated.

Hmm. Acutally, I think it needs to be "charsRead < *bufsize - 1" (or
"charsRead + 1 < *bufsize").  Oh well.

> 
> >       {
> >         (*buf)[charsRead++] = c;
> >       }
> >       else if ( charsRead == *bufsize )
> >       {
> >         /**
> >          * Buffer expansion failed; push the latest character back on
> >          * to the input stream, terminate the buffer, and return a failure
> >          * code.  It's up to the caller to decide what to do next.
> >          */
> >         ungetc( c, stream );
> >         (*buf)[charsRead-1] = 0;
> >         return 0;
> >       }
> >     }
> >   }
> >   if ( charsRead > 0 )
> >   {
> >     /**
> >      * We hit EOF while reading an alphanumeric sequence; terminate
> >      * the buffer.
> >      */
> >     (*buf)[charsRead] = 0;
> >     return 1;
> >   }
> >
> >   return 0;
> > }
> >
> > /**
> >  * Parse the sequence number out of the file name.  This assumes the
> >  * file name is of the form "toolchain<N>.sh".
> >  */
> > int getOrdinal( const char *filename )
> > {
> >   int ord;
> >   if ( sscanf( filename, "toolchain%d.sh", &ord ) == 1 )
> 
> I think I'd relax the requirement that it must be "toolchain" but that's
> a small matter.  You could make the output file have the same pattern as
> the input file but with the number incremented.

Yeah, this was an assumption to make things a little easier.

> 
> >     return ord;
> >
> >   return -1;
> 
> I like to use a conditional expression in such cases
> 
>   return sscanf(filename, "toolchain%d.sh", &ord) == 1 ? ord : -1;
> 
> > }
> 
> <snip>
> >   size_t bufsize = 80; // initial buffer size
> >   char *buffer = malloc( bufsize );
> 
> You should really check the buffer != 0 here.

Derp.  Agreed.

> 
> What I do in these cases in to start by setting buffer = 0 and
> bufsize = 0 so the first character triggers and expand operation.  You
> need to make the expand work correctly with a zero size so you can do
> 
>   new_size = size * 2 + 80;
> 
> or
> 
>   new_size = size ? 80 : size * 2;
> 
> but that avoids duplicating allocation code and checks.
> 

OTOH, setting the initial buffer size to something that handles most input
cases means you don't have to worry about reallocating most of the time.  

Of course, that can lull you into a false sense of security, as it did for
me.  Should have tried it with a really small buffer size to begin with.

> >   /**
> >    * Meat of the program - read the next symbol from the input file.
> >    * If it matches our search symbol, write the replacement symbol
> >    * to the output file - otherwise, copy the input symbol to the
> >    * output file.  **/
> >   while ( getNextSym( input, &buffer, &bufsize ) )
> >   {
> >     if ( strcmp( buffer, sym1 ) == 0 )
> >       fprintf( output, "%s", sym2 );
> >     else
> >       fprintf( output, "%s", buffer );
> >   }
> 
> Again I favour conditional expressions for cases like this:
> 
>   fputs(strcmp( buffer, sym1 ) == 0 ? sym2 : buffer, output);
> 

Doesn't fputs automatically append a newline?  

> >   free( buffer );
> >   fclose( input );
> >   fclose( output );
> >
> >   return 0;
> > }
> 
> <snip>
> Only the buffer overrun is really significant.
> 
> -- 
> Ben.

Good spots.  Again, no real defense other than tossing it off in a few
minutes.  And it was less motivated by helping FF and more by avoiding
working on something even more boring.  

[toc] | [prev] | [next] | [standalone]

#105339 — Re: solved Re: writing a c program to substitute text

John Bode <jfbode1029@gmail.com> writes:

> On Thursday, March 2, 2017 at 4:54:26 AM UTC-6, Ben Bacarisse wrote:
>> fred flintstone <fred@server.invalid> writes:
>> <snip>
>> 
>> There's a bug in the code, so I'll mention a couple of other things that
>> are not very important since I posting about something that does matter.
>> 
>
> In my defense, I tossed this off in about 15 minutes without putting too
> much thought into it, so I'm not surprised there are problems.  Like I
> said, this ain't professional-quality code.

It's always grim posting code to comp.lang.c since so many eyes see it,
but it's good for the soul and good for the group so thanks.

>> <snip>
>> > /**
>> >  * Read the next token from the input stream.  In this program,
>> >  * tokens are either sequences of alphanumeric characters, or individual
>> >  * non-alphanumeric characters.  Both are saved as strings to buf.
>> >  *
>> >  * For example, the input ">>text3.txt" would be tokenized as ">", ">",
>> >  * "text3", ".", "txt".
>> >  */
>> > int getNextSym( FILE *stream, char **buf, size_t *bufsize )
>> 
>> I would consider returning the number of characters read here.  It's
>> always a shame to return 0/1 when you have a potentially useful
>> alternative.  You might not need it now, but getNextSym is a potentially
>> reusable function.
>
> Wouldn't that be covered by calling strlen on the target buffer?

Oh sure, but since this function calculates the length of the token as
it goes, I'd be tempted to return it.  0 still means no token and != 0
still means OK, but the caller can immediately look at tok[len-1] when
that's useful.  Not a big deal but I dislike throwing information away.

<snip>
>> >       if ( charsRead < *bufsize || expand( buf, bufsize ) )
>> 
>> I think you need <= here or you can overflow the buffer when it gets
>> zero terminated.
>
> Hmm. Acutally, I think it needs to be "charsRead < *bufsize - 1" (or
> "charsRead + 1 < *bufsize").  Oh well.

Yes, I didn't think enough about the correction.  I think I had a
similar bug recently where the fix was to include equality and I just
trotted that out.

<snip>
>> What I do in these cases in to start by setting buffer = 0 and
>> bufsize = 0 so the first character triggers and expand operation.  You
>> need to make the expand work correctly with a zero size so you can do
>> 
>>   new_size = size * 2 + 80;
>> 
>> or
>> 
>>   new_size = size ? 80 : size * 2;
>> 
>> but that avoids duplicating allocation code and checks.
>
> OTOH, setting the initial buffer size to something that handles most input
> cases means you don't have to worry about reallocating most of the
> time.

I don't get that.  You have to allocate at least once no matter how you
do it.  My preference is to keep all the allocation in one place.  The
cost is either a test or an addition that is not strictly needed on
every allocation.

<snip>
>> >     if ( strcmp( buffer, sym1 ) == 0 )
>> >       fprintf( output, "%s", sym2 );
>> >     else
>> >       fprintf( output, "%s", buffer );
>> >   }
>> 
>> Again I favour conditional expressions for cases like this:
>> 
>>   fputs(strcmp( buffer, sym1 ) == 0 ? sym2 : buffer, output);
>
> Doesn't fputs automatically append a newline?

No, that's just puts.  I suspect a lot of people are put off using fputs
because of this historical hang-over.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#106110 — Re: solved Re: writing a c program to substitute text

On 03/02/2017 03:55 PM, Ben Bacarisse wrote:
> John Bode <jfbode1029@gmail.com> writes:
>
>> On Thursday, March 2, 2017 at 4:54:26 AM UTC-6, Ben Bacarisse wrote:
>>> fred flintstone <fred@server.invalid> writes:


[OP is leaving this quoted material because he didn't read it until 
right now and want to leave it as an editing decision]

>>>
>>> There's a bug in the code, so I'll mention a couple of other things that
>>> are not very important since I posting about something that does matter.
>>>
>>
>> In my defense, I tossed this off in about 15 minutes without putting too
>> much thought into it, so I'm not surprised there are problems.  Like I
>> said, this ain't professional-quality code.
>
> It's always grim posting code to comp.lang.c since so many eyes see it,
> but it's good for the soul and good for the group so thanks.
>

It's OP who is grateful for a decent result when he started into the 
question muttering about strings. It follows the development in 
_Intermediate Perl_ to do some small thing on github to try to figure it 
out. What's more, I'm also looking at _Programmieren in C_ chp 8, which 
I've never done because I worked through K&R2 whilst on MS.

https://github.com/TBlazer66/gcc

I have found that if I don't have C, then I don't really have perl, so 
it is that I wanted to have a program written in standard C99 to do the 
nuts and bolts things that C has to do to be the lower-level syntax of 
choice.


>>>> /**
>>>>  * Read the next token from the input stream.  In this program,
>>>>  * tokens are either sequences of alphanumeric characters, or individual
>>>>  * non-alphanumeric characters.  Both are saved as strings to buf.
>>>>  *
>>>>  * For example, the input ">>text3.txt" would be tokenized as ">", ">",
>>>>  * "text3", ".", "txt".
>>>>  */
>>>> int getNextSym( FILE *stream, char **buf, size_t *bufsize )
>>>
>>> I would consider returning the number of characters read here.  It's
>>> always a shame to return 0/1 when you have a potentially useful
>>> alternative.  You might not need it now, but getNextSym is a potentially
>>> reusable function.
>>
>> Wouldn't that be covered by calling strlen on the target buffer?
>
> Oh sure, but since this function calculates the length of the token as
> it goes, I'd be tempted to return it.  0 still means no token and != 0
> still means OK, but the caller can immediately look at tok[len-1] when
> that's useful.  Not a big deal but I dislike throwing information away.
>
> <snip>
>>>>       if ( charsRead < *bufsize || expand( buf, bufsize ) )
>>>
>>> I think you need <= here or you can overflow the buffer when it gets
>>> zero terminated.
>>
>> Hmm. Acutally, I think it needs to be "charsRead < *bufsize - 1" (or
>> "charsRead + 1 < *bufsize").  Oh well.
>
> Yes, I didn't think enough about the correction.  I think I had a
> similar bug recently where the fix was to include equality and I just
> trotted that out.
>
> <snip>
>>> What I do in these cases in to start by setting buffer = 0 and
>>> bufsize = 0 so the first character triggers and expand operation.  You
>>> need to make the expand work correctly with a zero size so you can do
>>>
>>>   new_size = size * 2 + 80;
>>>
>>> or
>>>
>>>   new_size = size ? 80 : size * 2;
>>>
>>> but that avoids duplicating allocation code and checks.
>>
>> OTOH, setting the initial buffer size to something that handles most input
>> cases means you don't have to worry about reallocating most of the
>> time.
>
> I don't get that.  You have to allocate at least once no matter how you
> do it.  My preference is to keep all the allocation in one place.  The
> cost is either a test or an addition that is not strictly needed on
> every allocation.
>
> <snip>
>>>>     if ( strcmp( buffer, sym1 ) == 0 )
>>>>       fprintf( output, "%s", sym2 );
>>>>     else
>>>>       fprintf( output, "%s", buffer );
>>>>   }
>>>
>>> Again I favour conditional expressions for cases like this:
>>>
>>>   fputs(strcmp( buffer, sym1 ) == 0 ? sym2 : buffer, output);
>>
>> Doesn't fputs automatically append a newline?
>
> No, that's just puts.  I suspect a lot of people are put off using fputs
> because of this historical hang-over.
>
> <snip>
>

My best effort to edit the source from this thread together is sub5.c . 
I'll see how this looks on my newly-minted mint partition. That would be 
its first port.

--
fred

[toc] | [prev] | [next] | [standalone]

#108200

John Bode <jfbode1029@gmail.com> writes:

> On Monday, February 27, 2017 at 5:58:44 AM UTC-6, fred flintstone wrote:
>> [..wanting to write a program to do text substitutions..]
>
> [Proposed problem statement]:
>
>    Replace all occurrences of <sym1> in toolchain<N>.sh
>    with <sym2> and write the result to toolchain<N+1>.sh.
>
> That's the kind of problem statement that most of us are looking for.
>
> So, you need to do the following:
>
>     1.  Parse input file name to separate out the ordinal from the rest
>         of the name;
>     2.  Create a new file name with the incremented ordinal;
>     3.  Tokenize the contents of the input file;
>     4.  Write each token as-is to the output file, *unless* it's the
>         symbol you want to substitute, in which case you write the
>         substitute symbol.
>
> [...]
>
> By "tokenizing" the input, I just mean breaking it into a sequence
> of strings (which is not *really* tokenization, but we're not
> going to worry about that right now); that will make it easier to
> match your target string, rather than trying to maintain state for
> every character.
>
> [..example program given..]

For the case under consideration, where the symbols being replaced are
alphanumeric "words" (ie, without adjacent alphanumeric characters on
either side), it seems easier to read in the whole file and just look
for occurrences of the word to be replaced, and in each case check the
ends to see if it should be replaced in that case.  At the top level
the code might look like this:


int
main( int argc, char *v[] ){
    char *in_name       =  argc > 3  ? v[1]                             : 0;
    char  buffer[          in_name   ? strlen( in_name ) + 3            : 1  ];
    char *out_name      =  in_name   ? transmogrify( buffer, in_name )  : 0;
    FILE *in            =  out_name  ? fopen( in_name, "r" )            : 0;
    FILE *out           =  in        ? fopen( out_name, "w" )           : 0;
    char *contents      =  in && out ? space_plus_contents_of( in )     : 0;

    if(  argc < 4        )  give_usage_message( v[0] );
    else if(  !out_name  )  printf( "  name: '%s' - no number found\n", v[1] );
    else if(  !in        )  printf( " input: '%s' - open failed\n", v[1] );
    else if(  !out       )  printf( "output: '%s' - open failed\n", out_name );
    else if(  !contents  )  printf( " input: '%s' - read failure\n", v[1] );
    else {
        substitute_and_write( contents+1, v[2], v[3], out );
    }

    free( contents );

    return  (in && !fclose(in)) & (out && !fclose(out)) ?  0 : EXIT_FAILURE;
}


after which the substitution/writing code might look like this:


void
substitute_and_write( char *contents, char *old, char *new, FILE *out ){
    typedef unsigned char UC;
    char *p = contents, *q;
    Size k = strlen( old );

    while(  q = strstr( p, old )  ){
        int bad =   isalnum( (UC){q[-1]} )  ||  isalnum( (UC){q[k]} );
        fprintf( out, "%.*s%s", (int){ q-p + bad*k }, p, bad ? "" : new );
        p = q+k;
    }
    fprintf( out, "%s", p );
}

[toc] | [prev] | [next] | [standalone]

#104941

On Sunday, February 26, 2017 at 5:28:30 AM UTC-8, David Brown wrote:

> I cannot fathom what you are trying to say or do here.

David, I think that the chatbot that is infesting comp.lang.c is becoming increasingly sophisticated.  I am marking these posts as spam, I hope that other people will join me.

[toc] | [prev] | [next] | [standalone]

#104947

On 02/27/2017 01:48 PM, jladasky@itu.edu wrote:
> On Sunday, February 26, 2017 at 5:28:30 AM UTC-8, David Brown wrote:
>
>> I cannot fathom what you are trying to say or do here.
>
> David, I think that the chatbot that is infesting comp.lang.c is becoming increasingly sophisticated.  I am marking these posts as spam, I hope that other people will join me.
>

Said someone who contributed zero C, all noise.
-- 
fred

[toc] | [prev] | [next] | [standalone]

#105051

On 27/02/17 23:16, fred flintstone wrote:
> On 02/27/2017 01:48 PM, jladasky@itu.edu wrote:
>> On Sunday, February 26, 2017 at 5:28:30 AM UTC-8, David Brown wrote:
>>
>>> I cannot fathom what you are trying to say or do here.
>>
>> David, I think that the chatbot that is infesting comp.lang.c is
>> becoming increasingly sophisticated.  I am marking these posts as
>> spam, I hope that other people will join me.
>>
> 
> Said someone who contributed zero C, all noise.

Fred, be careful about responding to insults with insults, especially
when you are new to a group.  jladasky is also not a regular here, but
the other three posts he has made were on topic.  It is possible that he
has simply mixed up posters here.

[toc] | [prev] | [next] | [standalone]

#105069

On 02/27/2017 11:47 PM, David Brown wrote:
> On 27/02/17 23:16, fred flintstone wrote:
>> On 02/27/2017 01:48 PM, jladasky@itu.edu wrote:
>>> On Sunday, February 26, 2017 at 5:28:30 AM UTC-8, David Brown wrote:
>>>
>>>> I cannot fathom what you are trying to say or do here.
>>>
>>> David, I think that the chatbot that is infesting comp.lang.c is
>>> becoming increasingly sophisticated.  I am marking these posts as
>>> spam, I hope that other people will join me.
>>>
>>
>> Said someone who contributed zero C, all noise.
>
> Fred, be careful about responding to insults with insults, especially
> when you are new to a group.  jladasky is also not a regular here, but
> the other three posts he has made were on topic.  It is possible that he
> has simply mixed up posters here.
>

Look, David, I don't want to lose momentum litigating this. I have to 
say that I'm glad to make your acquaintance. Whatever I did post brought 
you out of your shell, say what you like.

As to insults, I don't really mind being compared to software, but I 
will not be undermined as OP, as that is the way I felt, which is 
characteristic of meat machines.

I haven't looked at other threads yet, as it just looks beset by 
trolls/spam. If you would like to give me a reasonable recommendation 
for a starter killfile for clc, I'd read what you wrote.

I would like to play the Imitation Game, though, because that just 
sounds fun. OU in Ohio is in Athens. Yeah, there's an Athens in Ohio, 
about to be criminalized by Donald Trump.

Many in my cohort believe in the Jane Principle: that an emerging 
cyberintelligence will manifest herself as described in the science 
fiction of Mormon author Orson Scott Card. Like 3DBESNUB did in physics, 
this influenced a generation of lds lawyers, bankers, assassins, and me, 
fred flintstone, unbeliever in hocus pocus, but believer in a coming 
singularity. I'd be really impressed if the chatbot did google searches 
before saying anything, as do I....
-- 
fred

[toc] | [prev] | [next] | [standalone]

#105074

On 28/02/17 10:59, fred flintstone wrote:
> On 02/27/2017 11:47 PM, David Brown wrote:
>> On 27/02/17 23:16, fred flintstone wrote:
>>> On 02/27/2017 01:48 PM, jladasky@itu.edu wrote:
>>>> On Sunday, February 26, 2017 at 5:28:30 AM UTC-8, David Brown wrote:
>>>>
>>>>> I cannot fathom what you are trying to say or do here.
>>>>
>>>> David, I think that the chatbot that is infesting comp.lang.c is
>>>> becoming increasingly sophisticated.  I am marking these posts as
>>>> spam, I hope that other people will join me.
>>>>
>>>
>>> Said someone who contributed zero C, all noise.
>>
>> Fred, be careful about responding to insults with insults, especially
>> when you are new to a group.  jladasky is also not a regular here, but
>> the other three posts he has made were on topic.  It is possible that he
>> has simply mixed up posters here.
>>
> 
> Look, David, I don't want to lose momentum litigating this. 

"Litigating" ?  jladasky's "chatbot" accusation was not justified (as
far as I can see), but there is no need to take it /that/ seriously!

> I have to
> say that I'm glad to make your acquaintance.

I am glad to see learners in this newsgroup - helping folks like you is
one of the key reasons for the group.

> Whatever I did post brought
> you out of your shell, say what you like.

I must admit, I got a good laugh out of that one.  Have you looked at
the number of posts I make?  I have recently been accused (by someone I
respect, but in this case respectfully disagree with) of posting merely
because I like the sound of my own voice.

> 
> As to insults, I don't really mind being compared to software, but I
> will not be undermined as OP, as that is the way I felt, which is
> characteristic of meat machines.
> 
> I haven't looked at other threads yet, as it just looks beset by
> trolls/spam. If you would like to give me a reasonable recommendation
> for a starter killfile for clc, I'd read what you wrote.

The only people I have in my killfile (actually, Thunderbird message
filters) are "Jonas Eklundh", "TickleMe Elmo" and "Steve Carroll" - all
by name, rather than address, since it appears to be some sort of
chatbot that changes sender address regularly.  This bot sent a lot of
posts to c.l.c. recently.  I don't know if it has stopped, since the
messages (and any sub-threads replying to the bot) are automatically
killed by by newsreader.

Other regulars here have more extensive killfiles - but I encourage you
to make your own decisions about who might be worth listening to.

> 
> I would like to play the Imitation Game, though, because that just
> sounds fun. OU in Ohio is in Athens. Yeah, there's an Athens in Ohio,
> about to be criminalized by Donald Trump.
> 
> Many in my cohort believe in the Jane Principle: that an emerging
> cyberintelligence will manifest herself as described in the science
> fiction of Mormon author Orson Scott Card. Like 3DBESNUB did in physics,
> this influenced a generation of lds lawyers, bankers, assassins, and me,
> fred flintstone, unbeliever in hocus pocus, but believer in a coming
> singularity. I'd be really impressed if the chatbot did google searches
> before saying anything, as do I....

Please, stick to C.  Your questions on C made sense and were
interesting.  But these last couple of paragraphs are the kind of thing
that are likely to get /you/ killfiled by others.

[toc] | [prev] | [next] | [standalone]

#105077

On 28/02/17 09:59, fred flintstone wrote:

<snip>

> I haven't looked at other threads yet, as it just looks beset by
> trolls/spam. If you would like to give me a reasonable recommendation
> for a starter killfile for clc, I'd read what you wrote.

The obvious candidates are: fir because he writes gibberish and has no 
concept of engaging in intelligent discussion; Rick C Hodgin because he 
treats the group as a field for evangelism rather than a newsgroup for 
C; and BartC because he'd rather whinge than learn and after a while it 
gets rather trying.

> I would like to play the Imitation Game, though, because that just
> sounds fun. OU in Ohio is in Athens. Yeah, there's an Athens in Ohio,
> about to be criminalized by Donald Trump.

Oh, and we can maybe add one more to that list: fred flintstone because 
he seems to think that comp.lang.c is interested in random nonsense. 
We're not.

But I'll stay my hand unless you continue in that vein.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#105096

On 28/02/2017 12:03, Richard Heathfield wrote:
> On 28/02/17 09:59, fred flintstone wrote:
>
> <snip>
>
>> I haven't looked at other threads yet, as it just looks beset by
>> trolls/spam. If you would like to give me a reasonable recommendation
>> for a starter killfile for clc, I'd read what you wrote.
>
> The obvious candidates are: fir because he writes gibberish and has no
> concept of engaging in intelligent discussion; Rick C Hodgin because he
> treats the group as a field for evangelism rather than a newsgroup for
> C; and BartC because he'd rather whinge than learn and after a while it
> gets rather trying.

Or someone could look at people's posts, and at what they like to come 
here to do, and make up their own mind.

Some like to debate technical details, others seem to have an agenda 
against specific posters.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#105098

On 28/02/17 14:33, BartC wrote:
> On 28/02/2017 12:03, Richard Heathfield wrote:
>> On 28/02/17 09:59, fred flintstone wrote:
>>
>> <snip>
>>
>>> I haven't looked at other threads yet, as it just looks beset by
>>> trolls/spam. If you would like to give me a reasonable recommendation
>>> for a starter killfile for clc, I'd read what you wrote.
>>
>> The obvious candidates are: fir because he writes gibberish and has no
>> concept of engaging in intelligent discussion; Rick C Hodgin because he
>> treats the group as a field for evangelism rather than a newsgroup for
>> C; and BartC because he'd rather whinge than learn and after a while it
>> gets rather trying.
> 
> Or someone could look at people's posts, and at what they like to come
> here to do, and make up their own mind.

Agreed.  (I wrote the same thing myself.)

> 
> Some like to debate technical details, others seem to have an agenda
> against specific posters.
> 

And some seem to have an agenda against the C language, against
particular operating systems, against common utilities and tools,
against particular compilers, and against learning in general.

But it is a matter of personal choice and opinion who one agrees with or
disagrees with, and who one chooses to engage in debate and who one
chooses to ignore.

[toc] | [prev] | [next] | [standalone]

#105099

On 28/02/2017 13:43, David Brown wrote:
> On 28/02/17 14:33, BartC wrote:

>> Some like to debate technical details, others seem to have an agenda
>> against specific posters.
>>
>
> And some seem to have an agenda against the C language, against
> particular operating systems, against common utilities and tools,
> against particular compilers,

In other words, against poor design, needless complexity and 
over-reliance on parochial tools when working on open-source. But that's 
never personal (unless the people you're arguing with were those 
responsible).

> and against learning in general.

If someone ever gets the opportunity, writing a C compiler, or just part 
of one, is a very good way of learning the murky corners of the 
language, and can give useful insights into the rest. (It doesn't need 
to be written in C.)

It might not, however, change their opinions of the language, or of 
other compilers, for the better. (Except for an appreciation that they 
managed to do the job at all!)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#105232

On 02/28/2017 05:59 AM, BartC wrote:

> If someone ever gets the opportunity, writing a C compiler, or just part
> of one, is a very good way of learning the murky corners of the
> language, and can give useful insights into the rest. (It doesn't need
> to be written in C.)

That's why I find Plauger's _The Standard C Library_ so satisfying. It's 
not a compiler but more the murky corners. His implementation and 
comments on math.h are worth whatever price you pay for the book. It's 
outdated in the strict sense, but satisfying as a K&R type read.
>
> It might not, however, change their opinions of the language, or of
> other compilers, for the better. (Except for an appreciation that they
> managed to do the job at all!)
>

I've never done it, having tried. (Hold snide remarks, please) C_Dreamer 
has you in his killfile, but you're not in mine. I'm not gonna talk a 
bunch of smack about him on a post he can't read. I won't respond to his 
threat to killfile me but will say that my brother and I and aren't 
facebook friends, and it's a simple fact that a third of the people like 
you, a third of them don't, and a third don't know who you are.

I'm OP, and I'm not gonna stop talking about basketball. For example, 
does ITU have a basketball team? If not, what is the U for?
-- 
fred

[toc] | [prev] | [next] | [standalone]

#104952

On 27/02/17 22:48, jladasky@itu.edu wrote:
> On Sunday, February 26, 2017 at 5:28:30 AM UTC-8, David Brown wrote:
>
>> I cannot fathom what you are trying to say or do here.
>
> David, I think that the chatbot that is infesting comp.lang.c is
> becoming increasingly sophisticated.  I am marking these posts as
> spam, I hope that other people will join me.
>

There appears to be some sort of bot that recently infected c.l.c.  I 
have it killfiled, and don't know if it is still active.

But I don't think "fred flintstone" is a bot of some sort - what gives 
you that impression?

[toc] | [prev] | [next] | [standalone]

#104958

jladasky@itu.edu writes:
> On Sunday, February 26, 2017 at 5:28:30 AM UTC-8, David Brown wrote:
>
>> I cannot fathom what you are trying to say or do here.
>
> David, I think that the chatbot that is infesting comp.lang.c is
> becoming increasingly sophisticated.  I am marking these posts as
> spam, I hope that other people will join me.

I don't think "fred flintstone" is a chatboot or a troll.  His initial
posting was a bit hard to decode, but his followups have been more
reasonable.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#104761

On Sunday, February 26, 2017 at 12:14:23 PM UTC, fred flintstone wrote:

> Let's say that you're hard-coding a string between single quotes, for 
> example:
> 
> 'arrow'
> 
> , how do I declare this string to exist safely?
> 
> Do I malloc a 1000 because someone has to make an adult decision?
>
No, you write a function called mystrdup(). (There will also be a strdup
provided with your environment but it may not be available with
certain compiler settings.

char *mystdrdup(const char *str)
{
   size_t len - strlen(str):
   char *answer = malloc(len + 1);
   if(answer)
      strcpy(answer, str);
   else
      /* error handling here */;
 
   return answer;  
}

You call it like this

char *str = mystrdup("arrow");

Now the string is in heap memory, you can modify it, and it will stick
around until you delete it. For a simple string literal, the win
isn't very great. But if you are building a string, then  you can
construct it in a temporary buffer, then duplicate it. The buffer
is then free to construct the next string.

C is inherently unsafe. You have to keep track of which strings are
on the heap (so the easy answer is to say, "they all are"), and
who "owns" each string and thus has responsibility for freeing.

     

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web