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 5 of 5 — ← Prev page 1 2 3 4 [5]

#105138

On 28/02/17 17:33, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/02/17 13:20, fred flintstone wrote:
> [...]
>>> gcc -Wall -Wextra -o sub1 sub1.c >text1.txt
>>
>> You should add "-O1" to that list - it lets gcc do better analysis for
>> more warnings.
> 
> Why do you recommend -O1 rather than -O3?

-O1 is enough to enable the analysis passes that give better warnings -
as far as I know, you don't get more static analysis with greater
optimisation levels.

It can vary whether -O3 is actually any faster than -O2 - so usually -O2
is picked for "fast code".  If you need more than that, you probably
want to consider other flags like "-march=native" or "-ffast-math", and
perhaps using extra compiler features (attributes, etc.) if portability
is not an issue.

In general, I'd say "-O1" if you want to do debugging or view the
generated assembly (since the structure of your source code is more
visible in the generated output), and "-O2" if you want faster code.

> 
> If you want to write standard C, I'd also recommend
>     -std=c11 -pedantic-errors

Agreed, if you want to check for standards compliance (at least, as good
a check as you can conveniently get with little effort).  I don't
usually think about -pedantic flags, simply because for my own work I
use -std=gnu11 and make use of a number of gcc extensions - portability
across compilers is not an issue for most of what I do.  But certainly
sticking to the standards is a good idea for someone learning C.

> 
> If you use -pedantic rather than -pedantic-errors, some errors will be
> diagnosed with non-fatal warnings; that's ok if you treat warnings
> *very* seriously.
> 

I like to use -Werror - I /do/ treat warnings very seriously.  But
that's me - it is not necessarily a good idea for everyone.

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

#105150

David Brown <david.brown@hesbynett.no> writes:
> On 28/02/17 17:33, Keith Thompson wrote:
[...]
>> If you use -pedantic rather than -pedantic-errors, some errors will be
>> diagnosed with non-fatal warnings; that's ok if you treat warnings
>> *very* seriously.
>> 
>
> I like to use -Werror - I /do/ treat warnings very seriously.  But
> that's me - it is not necessarily a good idea for everyone.

Using -pedantic-errors rather than just -pedantic means that diagnostics
required by the C standard are fatal.  This is, in my opinion, a good
idea (except that not all the diagnostic produced by -pedantic[-errors]
are mandatory ones; there's one about string literals that exceed a
certain length).

Using -Werror means that *all* warnings issued by gcc become fatal --
which means you're trusting the gcc authors to decide what non-requires
diagnostics you have to avoid in your code.  For example,
    struct foo obj = { 0 };
is a perfectly good idiom, but some older versions of gcc will warn
about it if struct foo has more than one scalar member.

-- 
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]

#105151

On 28/02/17 20:40, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/02/17 17:33, Keith Thompson wrote:
> [...]
>>> If you use -pedantic rather than -pedantic-errors, some errors will be
>>> diagnosed with non-fatal warnings; that's ok if you treat warnings
>>> *very* seriously.
>>>
>>
>> I like to use -Werror - I /do/ treat warnings very seriously.  But
>> that's me - it is not necessarily a good idea for everyone.
>
> Using -pedantic-errors rather than just -pedantic means that diagnostics
> required by the C standard are fatal.  This is, in my opinion, a good
> idea (except that not all the diagnostic produced by -pedantic[-errors]
> are mandatory ones; there's one about string literals that exceed a
> certain length).
>
> Using -Werror means that *all* warnings issued by gcc become fatal --
> which means you're trusting the gcc authors to decide what non-requires
> diagnostics you have to avoid in your code.  For example,
>     struct foo obj = { 0 };
> is a perfectly good idiom, but some older versions of gcc will warn
> about it if struct foo has more than one scalar member.
>

-Werror means that /all/ warnings that are enabled will become fatal, 
which is what I want for most of my coding.  And I enable quite a few 
warnings, because most of them happen to match the way I like my code to 
be written - so a warning indicates a bug in my code (even if it is only 
a stylistic "bug").  Some warnings I don't enable, and of course my 
choice of warning flags will be different when compiling code from 
elsewhere.

So yes, I know what this flag means, and I use it intentionally.  But I 
quite understand that other people pick different flags.

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

#105178 — Re: gcc optimization levels

On 28/02/2017 19:38, David Brown wrote:

> In general, I'd say "-O1" if you want to do debugging

Since version 4.8, -Og might be more appropriate for debugging.

https://gcc.gnu.org/gcc-4.8/changes.html

> A new general optimization level, -Og, has been introduced. It
> addresses the need for fast compilation and a superior debugging
> experience while providing a reasonable level of run-time
> performance. Overall experience for development should be better than
> the default optimization level -O0.

Regards.

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

#105109

On 02/28/2017 07:20 AM, fred flintstone wrote:
> On 02/26/2017 03:55 PM, James R. Kuyper wrote:
>> On 02/26/2017 07:14 AM, fred flintstone wrote:
>> ...
>>> So there's 3DBESNUB type things ...
>>
>> Is this
>> <https://www.physics.byu.edu/faculty/christensen/Physics%20121/3D%20BE%20SNUB.htm>
>> what you're referring to?
...
> I want to draw the attention of respondents down here, as I announce
> myself safe on some type of first base, fulfilling D1 of the three D's.
> D1 might be a portrait of the client of the C application. The client
> is, first and foremost, me, and then everyone I take care of with the
> same methods. Many are simple pioneers, who don't need to be dished out
> to what's Out There.

The key problem is that your acronym is almost universally unfamiliar to 
the members of this newsgroup. The only reason that anyone had any idea 
what you were talking about is because I bothered searching, and dared 
to select a link that appeared in my search - a link in your message 
would have presented no greater danger than the link on that search 
page. Of course, the best approach would have been to define the term 
yourself, rather than providing a link to a definition.

...
>> ... Here's several
>> different options, each of which has different advantages and
>> disadvantages:
>>
>>     #define ARROW "arrow"
>>
>>     const char *parrow = "arrow";
>>     char arrow[] = "arrow";
>>     // Either of those definitions could be declared static
>>     // Either of those definitions could appear at either file scope or
>>     //    block scope.
>>
>>     parrow = malloc(sizeof "arrow"));
>>     memcpy(parrow, "arrow", sizeof "arrow");
>>
>
> Listen to me james. Have you ever used 'malloc' as a verb?

Yes, though I usually spell it as malloc(), to emphasize that I'm 
talking about a function. Similarly, I'll often append [] when talking 
about the name of an array, or <> when talking about the name of a C++ 
template.

> ... If you have a
> declaration like:
>
> const char *parrow = "arrow";
>
> , can one say that it has been malloced, or is it only correct to use
> the grown-up term of "allocated?" (Might there be a malloc right under
> the patina?)

I use "malloc()d" only to describe memory that has been dynamically 
allocated using the malloc() function. If I don't know whether malloc(), 
calloc(), or realloc() was used, I'll use the term "dynamically 
allocated" rather than "malloc()d". Nothing having to do with that line 
of code is dynamically allocated.

Your use of the string literal "arrow" requires the implementation to 
statically allocate an unnamed array of at least 6 chars, containing the 
values 'a', 'r', 'r', 'o', 'w', and '\0'. The value of the string 
literal itself is a pointer to the first character in that array, 'a'. 
Note that if "array" occurs anywhere else in your program, it might use 
the same array, or it might cause a separate array to be created - the 
standard allows for both possibilities, and real-world compilers exist 
that choose each of those two options. Any attempt to write to that 
array has undefined behavior.
parray is a pointer object that has either static or automatic storage 
duration, depending upon whether that declaration is a file scope or 
block scope.

...
> $ sh toolchain2.sh
> sub1.c: In function ‘main’:
> sub1.c:13:15: warning: unused variable ‘ext’ [-Wunused-variable]
>     const char *ext = "sh";
>                 ^
> sub1.c:12:15: warning: unused variable ‘base’ [-Wunused-variable]
>     const char *base = "toolchain";
>                 ^
> sub1.c:11:15: warning: unused variable ‘executable2’ [-Wunused-variable]
>     const char *executable2 = "mahershala";
>                 ^
> sub1.c:10:15: warning: unused variable ‘executable1’ [-Wunused-variable]
>     const char *executable1 = "arrow";
>                 ^
> sub1.c:8:7: warning: unused variable ‘version’ [-Wunused-variable]
>     int version, c, i;


I hope that you understand that the warnings above are entirely due to 
the fact that you made no use of those variables - they do not indicate 
that there is any problem with the definitions of those objects.

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

#105110

fred flintstone <fred@server.invalid> writes:
> On 02/26/2017 03:55 PM, James R. Kuyper wrote:
>> On 02/26/2017 07:14 AM, fred flintstone wrote:

[...]

> Listen to me james. Have you ever used 'malloc' as a verb? If you have a 
> declaration like:
>
> const char *parrow = "arrow";
>
> , can one say that it has been malloced, or is it only correct to use 
> the grown-up term of "allocated?" (Might there be a malloc right under 
> the patina?)

I won't speak for James, but I've certainly used malloc as a verb.

But it would not be correct to say that anything has been malloced in
the above declaration.  Memory for the pointer object parrow is
allocated either at program startup or on entry to the enclosing block,
depending on whether it's defined inside or outside a function body.
Memory for the string "arrow" is allocated at program startup.  (At
least logically; an implementation can arrange for them to be allocated
in any way that produces the same semantics.)  It's unlikely that any of
these will be allocated via an underlying call to malloc.

>>> Do I malloc a 1000 because someone has to make an adult decision?

It's hard to tell what you mean here, but I'd suggest that allocating
some amount that you assume is much more than you'll actually need is
*probably* poor practice.  For example, if you allocate 1000 bytes to
hold a line of text read from a file, then most of that space will be
wasted in the usual case.  On the other hand, I've certainly dealt with
text files with lines longer than 1000 bytes, and most of the tools I
use can deal with them just fine.

On the other other hand, allocating a large fixed chunk of memory is
simpler and can often be quicker.  But if you can manage to allocate
just what you need, whether it's large or small, that can often (but not
always) be the best approach.

[...]
>    while (1) {
>      c = fgetc (fptr);
>
>      if (c == EOF)
>        break;
>      else
>        putc (c, gptr);
>    }

The usual idiom for this kind of loop is:

    while ((c = fgetc(fptr)) != EOF) {
        putc(c, gptr);
    }

[...]

> 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;
> }

*If* you need this function (you probably don't), it doesn't need any
error handling other than returning a null pointer.  A low-level
function like this has no way of knowing how an allocation failure
should be handled.  Just let the caller know it failed, and the caller
can decide how to proceed.

[...]

-- 
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] | [standalone]

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

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

csiph-web