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

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

One works, the other doesn't?

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

Contents

  One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-03 17:39 -0500
    Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-04 00:20 +0000
    Re: One works, the other doesn't? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-04 06:53 +0000
    Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-04 09:45 -0500
      Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 10:34 -0500
        Re: One works, the other doesn't? mark.bluemel@gmail.com - 2019-11-05 07:45 -0800
          Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 10:53 -0500
            Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 08:04 -0800
              Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 11:29 -0500
                Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-05 23:24 +0100
                  Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-05 23:06 +0000
                    Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 12:31 +1300
                      Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-05 23:43 +0000
                        Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 12:54 +1300
                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 01:35 +0000
                            Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 15:16 +1300
                              Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 11:11 +0000
                          Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 01:59 -0800
                            Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 11:35 +0100
                              Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 08:57 -0800
                                Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:24 +1300
                                Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 22:59 +0100
                                  Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 14:37 -0800
                                    Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 00:58 +0100
                                      Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 02:08 -0800
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 15:43 +0100
                                          Re: One works, the other doesn't? Robert Wessel <robertwessel2@yahoo.com> - 2019-11-07 16:15 -0600
                                    Re: One works, the other doesn't? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-10 20:01 +0000
                                      Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-11 15:26 +1300
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-11 12:37 +0100
                            Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:21 +1300
                              Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 10:39 -0800
                                Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:47 +1300
                                Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 08:14 +1300
                                  Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 12:30 -0800
                                  Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 21:04 -0800
                                    Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 01:37 -0800
                                      Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 01:38 -0800
                                    Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-10 08:32 +1300
                                      Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:09 -0800
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-29 11:33 +0100
                                          Re: One works, the other doesn't? Öö Tiib <ootiib@hot.ee> - 2019-11-30 14:20 -0800
                                        Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-12-01 12:15 +1300
                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 10:07 +0100
                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 10:58 +0000
                            Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 10:05 +0100
                    Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 09:52 +0100
                      Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-06 00:56 -0800
                        Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-06 01:00 -0800
                      Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 11:32 +0000
                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 23:11 +0100
                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 23:22 +0000
                            Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 01:04 +0100
                              Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 01:13 +0000
                                Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 10:22 +0100
                                  Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 11:51 +0000
                                    Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 15:58 +0100
                                      Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 16:34 +0000
                                        Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-07 12:40 -0500
                                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 17:57 +0000
                                            Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-07 21:14 -0800
                                              Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-08 09:45 +0000
                                                Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-08 09:56 -0800
                                                  Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-08 19:47 +0000
                                                    Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:14 +1300
                                                    Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-08 19:10 -0800
                                                      Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-09 12:24 +0000
                                                  Like an old married couple... (Was: One works, the other doesn't?) gazelle@shell.xmission.com (Kenny McCormack) - 2019-11-08 20:25 +0000
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 19:58 +0100
                                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 19:31 +0000
                                        Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 08:56 +1300
                                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 20:06 +0000
                                            Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 09:21 +1300
                                              Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 21:20 +0000
                                                Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 10:28 +1300
                                                  Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 22:35 +0000
                                                    Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:22 +1300
                                      Re: One works, the other doesn't? jadill33@gmail.com - 2019-11-07 08:37 -0800
                                        Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 08:52 -0800
                                          Re: One works, the other doesn't? jadill33@gmail.com - 2019-11-07 09:52 -0800
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 20:04 +0100
                                        Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 19:50 -0800
              Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 18:05 +0100
                Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 09:28 -0800
                  Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 19:02 +0100
                    Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-05 23:21 +0100
                      Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 18:36 +0100
        Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-05 12:51 -0500
          Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 18:35 -0500
            Re: One works, the other doesn't? Barry Schwarz <schwarzb@delq.com> - 2019-11-05 17:53 -0800
            Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-06 09:33 -0500
        Re: One works, the other doesn't? Barry Schwarz <schwarzb@delq.com> - 2019-11-05 13:36 -0800
        Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-07 10:17 +0100
          Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 12:19 +0000
            Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-07 18:59 +0100
              Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 00:02 +0000
                Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-20 10:54 +0100
                  Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-20 11:14 +0000
                    Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-20 13:22 +0100
                      Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:54 -0800
                    Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-20 08:42 -0800
                      Re: One works, the other doesn't? Manfred <noname@add.invalid> - 2019-11-21 18:56 +0100
                        Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-22 01:07 +0000
                          Re: One works, the other doesn't? Manfred <noname@add.invalid> - 2019-11-22 15:27 +0100
                  Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:47 -0800
          Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-07 18:41 -0500
      Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 17:39 +0100
        Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 11:47 -0500
          Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 17:54 +0100
            Re: One works, the other doesn't? luser droog <luser.droog@gmail.com> - 2019-11-05 09:00 -0800
          Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 21:02 -0800
            Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-09 02:09 -0500

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#147558 — One works, the other doesn't?

=========================================================================
standalone snippet works for small number of array items...
(looks for dupes in an array, copies the unique values to a dynamically 
sized array)
=========================================================================
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(void) {
   char *arr[] = {"This","array","may","contain","dupe","dupe","values"};
   int arrsize = sizeof(arr)/sizeof(arr[0]);

   int cnt = 0;
   char **finalarr = malloc(sizeof(char*));
   for(int i=0;i<arrsize;i++) {
     while (i<arrsize-1 && strcasecmp(arr[i],arr[i+1])==0) {i++;}
      finalarr = malloc(sizeof(char*));
      finalarr[cnt] = arr[i];
      printf("%d %s   ",cnt,finalarr[cnt]);
      cnt++;
    }	

   free(finalarr);
}


It runs fine - does all six for..loops (seven array items less one dupe) 
and reports correct results: unique list of values added to a 
dynamically sized array.

0 This
1 array
2 may
3 contain
4 dupe
5 values


=========================================================================
... but virtually identical code doesn't work inline of larger program.

On MSYS2 the program does a few iterations, hangs for a few sections, 
then aborts (core dump)

On Windows after a few iteration of the for..loop it throws an *.exe 
quit working.

=========================================================================
int cnt=0;
char **finalarr = malloc(sizeof(char*));
for(i=0;i<arrsize;i++) {
   while (i<arrsize-1 && strcasecmp(randoms3[i],randoms3[i+1])==0) {i++;}
    finalarr = malloc(sizeof(char*));
    finalarr[cnt] = randoms3[i];
    printf("%d %s ",cnt,finalarr[cnt]);
    cnt++;			
}



Am I allocating memory incorrectly?

[toc] | [next] | [standalone]

#147562

On 03/11/2019 22:39, DFS wrote:
> =========================================================================
> standalone snippet works for small number of array items...
> (looks for dupes in an array, copies the unique values to a dynamically 
> sized array)
> =========================================================================
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> 
> int main(void) {
>    char *arr[] = {"This","array","may","contain","dupe","dupe","values"};
>    int arrsize = sizeof(arr)/sizeof(arr[0]);
> 
>    int cnt = 0;
>    char **finalarr = malloc(sizeof(char*));
>    for(int i=0;i<arrsize;i++) {
>      while (i<arrsize-1 && strcasecmp(arr[i],arr[i+1])==0) {i++;}
>       finalarr = malloc(sizeof(char*));
>       finalarr[cnt] = arr[i];
>       printf("%d %s   ",cnt,finalarr[cnt]);
>       cnt++;
>     }
> 
>    free(finalarr);
> }
> 
> 
> It runs fine - does all six for..loops (seven array items less one dupe) 

I find it crashes on this short array too.

Have a look at the finalarr array: you allocate one entry of 8 bytes.

Then in the loop, you reallocate that one entry (the old one is still 
allocated but disregarded). But then you proceed to write to element 
[cnt], when no element beyond [0] exists.

> Am I allocating memory incorrectly?

Oh. Short answer: no.

You're using an array of char*, but you don't know the final size of 
that array so can't preallocate it. This is a classic problem in C.

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

#147565

On Sun, 2019-11-03, DFS wrote:
> =========================================================================
> standalone snippet works for small number of array items...
> (looks for dupes in an array, copies the unique values to a dynamically 
> sized array)
> =========================================================================
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
>
> int main(void) {
>    char *arr[] = {"This","array","may","contain","dupe","dupe","values"};
>    int arrsize = sizeof(arr)/sizeof(arr[0]);

I recommend heavy use of 'const' here.

>    int cnt = 0;
>    char **finalarr = malloc(sizeof(char*));
>    for(int i=0;i<arrsize;i++) {
>      while (i<arrsize-1 && strcasecmp(arr[i],arr[i+1])==0) {i++;}
>       finalarr = malloc(sizeof(char*));
>       finalarr[cnt] = arr[i];

You malloc a single pointer (N+1 times) but then treat it as an array
of pointers, of a size > 1.

>       printf("%d %s   ",cnt,finalarr[cnt]);
>       cnt++;
>     }	
>
>    free(finalarr);

And you only free once by the way.

> }

...

> Am I allocating memory incorrectly?

Yes.  Wasn't this discussed last week?  I didn't follow that thread,
and don't know if you were involved.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#147576

On 11/3/19 5:39 PM, DFS wrote:
> =========================================================================
> standalone snippet works for small number of array items...
> (looks for dupes in an array, copies the unique values to a dynamically 
> sized array)
> =========================================================================
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> 
> int main(void) {
>    char *arr[] = {"This","array","may","contain","dupe","dupe","values"};
>    int arrsize = sizeof(arr)/sizeof(arr[0]);
> 
>    int cnt = 0;
>    char **finalarr = malloc(sizeof(char*));
>    for(int i=0;i<arrsize;i++) {
>      while (i<arrsize-1 && strcasecmp(arr[i],arr[i+1])==0) {i++;}
>       finalarr = malloc(sizeof(char*));
>       finalarr[cnt] = arr[i];
>       printf("%d %s   ",cnt,finalarr[cnt]);
>       cnt++;
>     }	
> 
>    free(finalarr);
> }
> 
> 
> It runs fine - does all six for..loops (seven array items less one dupe) 
> and reports correct results: unique list of values added to a 
> dynamically sized array.
> 
> 0 This
> 1 array
> 2 may
> 3 contain
> 4 dupe
> 5 values
> 
> 
> =========================================================================
> ... but virtually identical code doesn't work inline of larger program.
> 
> On MSYS2 the program does a few iterations, hangs for a few sections, 
> then aborts (core dump)
> 
> On Windows after a few iteration of the for..loop it throws an *.exe 
> quit working.
> 
> =========================================================================
> int cnt=0;
> char **finalarr = malloc(sizeof(char*));

malloc() can fail, for reasons that aren't under your control. If it
does, it returns a null pointer. If your code made any attempt to
dereference that pointer, it would have had undefined behavior. Luckily
(?) your code never dereferences the value returned by this call to
malloc(), so that issue never comes up. That raises the question of why
you bothered allocating memory that you never intended to use. However,
your code does dereference the pointer returned by it's second call to
malloc().

You should always check the value returned by malloc() to determine
whether it's null, and take appropriate action if it is (what
constitutes "appropriate action" is up to you).

> for(i=0;i<arrsize;i++) {
>    while (i<arrsize-1 && strcasecmp(randoms3[i],randoms3[i+1])==0) {i++;}

As far as I can tell, the only difference between this version and the
previous one appears to be that you're replacing arr[] with randoms3[].
You should have explicitly mentioned that. Since that is the only
difference, you should also have shown us how randoms3[] was declared
and initialized, so we could compare with the way arr was declared and
initialized, in order to make a guess as to why the difference between
the two matters.

>     finalarr = malloc(sizeof(char*));

The variable finalarr currently holds the only copy, anywhere in your
program, of the value returned by a previous call to malloc(). You are
replacing that value with a new one. That means that you will never
again be able to access the memory allocated by that previous call. You
also won't be able to pass that previous value to free(), which makes
this a memory leak.

The following makes it easy to be certain that you're allocating the
right amount of memory, regardless of what the type of finalarr is:

      finalarr = malloc(sizeof *finalarr);

>     finalarr[cnt] = randoms3[i];

You only allocated enough space for a single pointer to char. Therefore,
whenever cnt is greater than 0, you're accessing memory that was not
allocated for use by this code. You have the same problem with both
versions of your code. If the first version of this code appeared to
work, that was purely an unlucky accident. It's unlucky because it left
you unaware of the defect in your code.
I suspect that the difference is due to some data being in different
locations in the two different versions of your code. With your previous
version, finalarr[cnt] just happened to never refer to a piece of memory
which it was unsafe to write to. With this version, it does. That would
be a particularly plausible result if randoms3[] refers to dynamically
allocated memory.

>     printf("%d %s ",cnt,finalarr[cnt]);
>     cnt++;			
> }
> 
> 
> 
> Am I allocating memory incorrectly?

Quite thoroughly. I'm not sure you did anything correct with regards to
your use of dynamically allocated memory.

Also, there's no need for you to use dynamically allocated memory for
this purpose:

    int cnt=0;
    for(i=0;i<arrsize;i++) {
       while (i<arrsize-1 && strcasecmp(randoms3[i],
           randoms3[i+1])==0)
       {i++}

        printf("%d %s ",cnt, randoms3[i]);
        cnt++;			
    }

It's possible that the full original context of this code provides a
good reasons for dynamically allocating this memory. If so, let us know,
and we can give you advice on how to do it properly (which will probably
involve the use of realloc()).

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

#147614

On 11/4/2019 9:45 AM, James Kuyper wrote:
> On 11/3/19 5:39 PM, DFS wrote:
>> =========================================================================
>> standalone snippet works for small number of array items...
>> (looks for dupes in an array, copies the unique values to a dynamically
>> sized array)
>> =========================================================================
>> #include <stdlib.h>
>> #include <stdio.h>
>> #include <string.h>
>>
>> int main(void) {
>>     char *arr[] = {"This","array","may","contain","dupe","dupe","values"};
>>     int arrsize = sizeof(arr)/sizeof(arr[0]);
>>
>>     int cnt = 0;
>>     char **finalarr = malloc(sizeof(char*));
>>     for(int i=0;i<arrsize;i++) {
>>       while (i<arrsize-1 && strcasecmp(arr[i],arr[i+1])==0) {i++;}
>>        finalarr = malloc(sizeof(char*));
>>        finalarr[cnt] = arr[i];
>>        printf("%d %s   ",cnt,finalarr[cnt]);
>>        cnt++;
>>      }	
>>
>>     free(finalarr);
>> }
>>
>>
>> It runs fine - does all six for..loops (seven array items less one dupe)
>> and reports correct results: unique list of values added to a
>> dynamically sized array.
>>
>> 0 This
>> 1 array
>> 2 may
>> 3 contain
>> 4 dupe
>> 5 values
>>
>>
>> =========================================================================
>> ... but virtually identical code doesn't work inline of larger program.
>>
>> On MSYS2 the program does a few iterations, hangs for a few sections,
>> then aborts (core dump)
>>
>> On Windows after a few iteration of the for..loop it throws an *.exe
>> quit working.
>>
>> =========================================================================
>> int cnt=0;
>> char **finalarr = malloc(sizeof(char*));
> 
> malloc() can fail, for reasons that aren't under your control. If it
> does, it returns a null pointer. If your code made any attempt to
> dereference that pointer, it would have had undefined behavior. Luckily
> (?) your code never dereferences the value returned by this call to
> malloc(), so that issue never comes up. That raises the question of why
> you bothered allocating memory that you never intended to use. 

I intended to use it, of course.  I thought that was the correct way to 
initialize the array, with memory for one array entry.  Then during the 
for..loop add memory for one more entry.  I bet the fix is easy, but it 
eludes me.


> However, your code does dereference the pointer returned by it's second call to
> malloc().  
> You should always check the value returned by malloc() to determine
> whether it's null, and take appropriate action if it is (what
> constitutes "appropriate action" is up to you).

"always check"... good practice, I agree, but 90% of the example code 
out there doesn't check.


>> for(i=0;i<arrsize;i++) {
>>     while (i<arrsize-1 && strcasecmp(randoms3[i],randoms3[i+1])==0) {i++;}
> 
> As far as I can tell, the only difference between this version and the
> previous one appears to be that you're replacing arr[] with randoms3[].
> You should have explicitly mentioned that. Since that is the only
> difference, you should also have shown us how randoms3[] was declared
> and initialized, so we could compare with the way arr was declared and
> initialized, in order to make a guess as to why the difference between
> the two matters.

randoms3[] was declared and initialized this way:

char **randoms3 = malloc(sizeof(char*) * arrsize);

where arrsize is the value from the command line.



>>      finalarr = malloc(sizeof(char*));
> 
> The variable finalarr currently holds the only copy, anywhere in your
> program, of the value returned by a previous call to malloc(). You are
> replacing that value with a new one. That means that you will never
> again be able to access the memory allocated by that previous call. You
> also won't be able to pass that previous value to free(), which makes
> this a memory leak.
> 
> The following makes it easy to be certain that you're allocating the
> right amount of memory, regardless of what the type of finalarr is:
> 
>        finalarr = malloc(sizeof *finalarr);
> 
>>      finalarr[cnt] = randoms3[i];
> 
> You only allocated enough space for a single pointer to char. Therefore,
> whenever cnt is greater than 0, you're accessing memory that was not
> allocated for use by this code. You have the same problem with both
> versions of your code. If the first version of this code appeared to
> work, that was purely an unlucky accident. It's unlucky because it left
> you unaware of the defect in your code.

'unlucky'... I like it.


> I suspect that the difference is due to some data being in different
> locations in the two different versions of your code. With your previous
> version, finalarr[cnt] just happened to never refer to a piece of memory
> which it was unsafe to write to. With this version, it does. That would
> be a particularly plausible result if randoms3[] refers to dynamically
> allocated memory.
> 
>>      printf("%d %s ",cnt,finalarr[cnt]);
>>      cnt++;			
>> }
>>
>>
>>
>> Am I allocating memory incorrectly?
> 
> Quite thoroughly. I'm not sure you did anything correct with regards to
> your use of dynamically allocated memory.



> Also, there's no need for you to use dynamically allocated memory for
> this purpose:
> 
>      int cnt=0;
>      for(i=0;i<arrsize;i++) {
>         while (i<arrsize-1 && strcasecmp(randoms3[i],
>             randoms3[i+1])==0)
>         {i++}
> 
>          printf("%d %s ",cnt, randoms3[i]);
>          cnt++;			
>      }


?  I never wrote that.  You concocted it somehow.  If you're just 
showing it as an example, I agree there's no need for dyn alloc mem there.


What I wrote was:

printf("%d %s ",cnt,finalarr[cnt]);

so I could see what was copied to finalarr after each loop iteration.



> It's possible that the full original context of this code provides a
> good reasons for dynamically allocating this memory. If so, let us know,
> and we can give you advice on how to do it properly (which will probably
> involve the use of realloc()).

Thanks for your assessment James.  Before you answered I tried realloc 
in the larger program and it appears to work, in that it copies the 
unique data to the finalarr (whether it's 10 elements or 1000000 
elements), but the program fails and quits after the next to last line.


  int cnt=0;
  char **finalarr = malloc(sizeof(char*));
  for(i=0;i<arrsize;i++) {
   while (i<arrsize-1 && strcasecmp(randoms3[i],randoms3[i+1])==0) {i++;}
    finalarr = realloc(finalarr, sizeof(char*) * (cnt+1));
    finalarr[cnt] = randoms3[i];
    printf("%d %s \n",cnt,finalarr[cnt]);
    cnt++;			
  }
  printf("%d here\n",cnt);
  printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);



It also fails after the next to last line using your suggestion:
finalarr = malloc(sizeof *finalarr);


  int cnt=0;
  char **finalarr = malloc(sizeof(char*));
  for(i=0;i<arrsize;i++) {
  while (i<arrsize-1 && strcasecmp(randoms3[i],randoms3[i+1])==0) {i++;}
   finalarr = malloc(sizeof *finalarr);
   finalarr[cnt] = randoms3[i];
   cnt++;			
  }
  printf("%d here\n",cnt);
  printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);




============================================================================
full code listing
============================================================================
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <Windows.h>


//usage
//progname N L H
//N = number of array elements to be created
//L = low  end of length of random string
//H = high end of length of random string
//usage example: ./rand 500 4 8

//vars
int i=0, j=0, k=0;
char charset[62] = 
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
short charsetLen = 62;

//program timing
LARGE_INTEGER frequency,master,start,end;
double elapsedtime(LARGE_INTEGER startingtimer)
{
   QueryPerformanceCounter(&end);
   return (end.QuadPart - startingtimer.QuadPart) / 
(double)frequency.QuadPart;
}

//string compare function for qsort
int comparechar( const void *a, const void *b){
         const char **chara = (const char **)a;
     const char **charb = (const char **)b;
     return strcasecmp(*chara, *charb);
}

//get random number from within range
int randNbr(int low, int high) {
     return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
}

//build random string of random length
char *randStr(int randLen) {
     char *randStr = malloc(sizeof(char) * (randLen + 1));
     for(i=0; i<randLen; i++) {
         randStr[i] = charset[randNbr(0,charsetLen-1)];
     }
     randStr[randLen] = '\0';
     return randStr;
}

//copy elements of arrays a and b into existing array c
void combinearrays(int lenA, int lenB, char *a[], char *b[], char *c[]) {
     printf("combining... ");
     memcpy(c     , a, sizeof(char*) * lenA);
     memcpy(c+lenA, b, sizeof(char*) * lenB);
     printf("combined arrays 1 and 2\nnew unsorted array contains %d 
elements\n",lenA+lenB);
}


int main(int argc, char *argv[])
{
     char *dupes[] = 
{"These","are","the","dupe","values","for","each","array"};
     int dupecnt = sizeof(dupes)/sizeof(dupes[0]);

     //size of array (including dupes)
     int arrsize = atoi(argv[1]) + (2*dupecnt);

     //size of random strings.
     int lo = atoi(argv[2]);
     int hi = atoi(argv[3]);

     //begin timer
     QueryPerformanceFrequency(&frequency);
     QueryPerformanceCounter(&master);
     QueryPerformanceCounter(&start);

     //create and size 3 arrays
     //first 2 are half the size of the 3rd
     //they will later be combined into the 3rd
     char **randoms1 = malloc(sizeof(char*) * arrsize/2);
     char **randoms2 = malloc(sizeof(char*) * arrsize/2);
     char **randoms3 = malloc(sizeof(char*) * arrsize);

     //seed
     srand(time(NULL));

     //populate 2 arrays with random strings of random lengths
     for(j=0;j<arrsize/2-dupecnt;j++) {
         randoms1[j] = randStr(randNbr(lo,hi));
         randoms2[j] = randStr(randNbr(lo,hi));
     }

     //add dupes to each array
     for(i=0;i<dupecnt;i++) {
         k = (arrsize/2)+i-dupecnt;
         randoms1[k] = dupes[i];
         randoms2[k] = dupes[i];
     }


     //show top and bottom 10
     printf("\n\nItem        Array 1             Array2\n");
     printf("-------------------------------------------------\n");
     for(i=0;i<arrsize/2;i++) {
         if (i<10 || i>(arrsize/2-11)) {
             printf("%-7d  %-18s %-18s \n",i+1, randoms1[i], randoms2[i]);
         }
     }

     printf("\n%.4fs to create %d random string elements (+ add 
dupes)\n",elapsedtime(start),arrsize-(2*dupecnt));


     //sort - combine the unsorted arrays into one, then qsort large array
     combinearrays(arrsize/2, arrsize/2, randoms1, randoms2, randoms3);
     QueryPerformanceCounter(&start);
     printf("qsorting... ");
     qsort(randoms3, arrsize, sizeof(char*), comparechar);
     printf("%.4fs\n",elapsedtime(start));


//-------------------------------------------------------------------------------
//next two sections count unique items and copy to final array
//I want to combine them, and copy unique items as they're being counted
//-------------------------------------------------------------------------------

/*
     //count unique items in existing randoms array
     int cnt=0;
     for(i=0;i<arrsize;i++) {
         while (i<arrsize-1 && strcasecmp(randoms3[i],randoms3[i+1])==0) 
{i++;}
     cnt++;
     }

		//same routine as above, but create a new array
		//to hold unique values, then populate it
		printf("removing dupes... ");
		char **finalarr = malloc(sizeof(char*) * cnt);
			cnt=0;
			for(i=0;i<arrsize;i++) {
					while (i<arrsize-1 && strcasecmp(randoms3[i],randoms3[i+1])==0) {i++;}
			finalarr[cnt] = randoms3[i];
			cnt++;
		}
     printf("removed %d dupes\n",arrsize-cnt);
	
*/


//-------------------------------------------------------------------------------
//this is the section we've been talking about.
//-------------------------------------------------------------------------------

	printf("removing dupes... \n");
	QueryPerformanceCounter(&start);
     int cnt=0;
     char **finalarr = malloc(sizeof(char*));
     for(i=0;i<arrsize;i++) {
	while (i<arrsize-1 && strcasecmp(randoms3[i],randoms3[i+1])==0) {i++;}
			//finalarr = realloc(finalarr, sizeof(char*) * (cnt+1));
			finalarr = malloc(sizeof *finalarr);
			finalarr[cnt] = randoms3[i];
			//printf("%d %s \n",cnt,finalarr[cnt]);
			cnt++;			
		}
		printf("%d here\n",cnt);
     printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);
-------------------------------------------------------------------------------



     //print top and bottom data
     printf("\ncombined data\ndeduped and sorted 
lowercase\n---------------------------------\n");
     for(i=0;i<cnt;i++) {
         if (i<10 || i>(cnt-11)) {
             printf("%-6d  %s\n",i+1, finalarr[i]);
         }
     }

     printf("program ran in %.4fs seconds\n",elapsedtime(master));

     //finish
     free(randoms1);
     free(randoms2);
     free(randoms3);
     free(finalarr);
     printf("Done");
     exit(0);
}
============================================================================

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

#147615

On Tuesday, 5 November 2019 15:34:32 UTC, DFS  wrote:

>      printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);

"%.4s" is a (slightly unusual) format specifier for a string. It's a 
totally unsuitable format specifier for a double value, which I think
is what elapsedtime() returns. I'd kind of expect it to fail, in some
unpredictable manner, as the printf routine tries to treat a double as
a pointer-to-char and disappears into some abyss or other.

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

#147616

On 11/5/2019 10:45 AM, mark.bluemel@gmail.com wrote:
> On Tuesday, 5 November 2019 15:34:32 UTC, DFS  wrote:
> 
>>       printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);
> 
> "%.4s" is a (slightly unusual) format specifier for a string. 
> It's a
> totally unsuitable format specifier for a double value, which I think
> is what elapsedtime() returns. I'd kind of expect it to fail, in some
> unpredictable manner, as the printf routine tries to treat a double as
> a pointer-to-char and disappears into some abyss or other.


Dude!  It's a format specifier for a double (elapsed time), but I 
inadvertently dropped the f  (should be .4fs, where the s is short for 
seconds).

This was causing my program to fail, and I didn't look closely enough at 
that line. Now I'm golden - I think.

Thanks for spotting it!

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

#147618

On Tuesday, 5 November 2019 15:52:48 UTC, DFS  wrote:
> On 11/5/2019 10:45 AM, mark.bluemel@gmail.com wrote:
> > On Tuesday, 5 November 2019 15:34:32 UTC, DFS  wrote:
> > 
> >>       printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);
> > 
> > "%.4s" is a (slightly unusual) format specifier for a string. 
> > It's a
> > totally unsuitable format specifier for a double value, which I think
> > is what elapsedtime() returns. I'd kind of expect it to fail, in some
> > unpredictable manner, as the printf routine tries to treat a double as
> > a pointer-to-char and disappears into some abyss or other.
> 
> 
> Dude!  It's a format specifier for a double (elapsed time), but I 
> inadvertently dropped the f  (should be .4fs, where the s is short for 
> seconds).
> 
> This was causing my program to fail, and I didn't look closely enough at 
> that line. Now I'm golden - I think.
> 
> Thanks for spotting it!
>
If you use a good modern IDE, it will warn you when the format string 
and the arguments don't match.

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

#147620

On 11/5/2019 11:04 AM, Malcolm McLean wrote:
> On Tuesday, 5 November 2019 15:52:48 UTC, DFS  wrote:
>> On 11/5/2019 10:45 AM, mark.bluemel@gmail.com wrote:
>>> On Tuesday, 5 November 2019 15:34:32 UTC, DFS  wrote:
>>>
>>>>        printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);
>>>
>>> "%.4s" is a (slightly unusual) format specifier for a string.
>>> It's a
>>> totally unsuitable format specifier for a double value, which I think
>>> is what elapsedtime() returns. I'd kind of expect it to fail, in some
>>> unpredictable manner, as the printf routine tries to treat a double as
>>> a pointer-to-char and disappears into some abyss or other.
>>
>>
>> Dude!  It's a format specifier for a double (elapsed time), but I
>> inadvertently dropped the f  (should be .4fs, where the s is short for
>> seconds).
>>
>> This was causing my program to fail, and I didn't look closely enough at
>> that line. Now I'm golden - I think.
>>
>> Thanks for spotting it!
>>
> If you use a good modern IDE, it will warn you when the format string
> and the arguments don't match.


I'm using geany and Tiny C Compiler (Windows).  Neither one catches it 
(I wouldn't expect Geany to).

printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);

tcc -Wall -o rand.exe random_strings_clc_final.c
compilation finished successfully


But gcc (on MSYS2) does:

$ gcc -Wall -o rand.exe random_strings_clc_final.c
random_strings_clc_final.c: In function ‘main’:
random_strings_clc_final.c:132:16: warning: format ‘%s’ expects argument 
of type ‘char *’, but argument 2 has type ‘double’ [-Wformat=]
   132 |     printf("%.4s remove %d 
dupes\n",elapsedtime(start),arrsize-cnt);
       |             ~~~^                    ~~~~~~~~~~~~~~~~~~
       |                |                    |
       |                char *               double
       |             %.4f

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

#147635

On 05/11/2019 17:29, DFS wrote:
> On 11/5/2019 11:04 AM, Malcolm McLean wrote:
>> On Tuesday, 5 November 2019 15:52:48 UTC, DFS  wrote:
>>> On 11/5/2019 10:45 AM, mark.bluemel@gmail.com wrote:
>>>> On Tuesday, 5 November 2019 15:34:32 UTC, DFS  wrote:
>>>>
>>>>>        printf("%.4s remove %d 
>>>>> dupes\n",elapsedtime(start),arrsize-cnt);
>>>>
>>>> "%.4s" is a (slightly unusual) format specifier for a string.
>>>> It's a
>>>> totally unsuitable format specifier for a double value, which I think
>>>> is what elapsedtime() returns. I'd kind of expect it to fail, in some
>>>> unpredictable manner, as the printf routine tries to treat a double as
>>>> a pointer-to-char and disappears into some abyss or other.
>>>
>>>
>>> Dude!  It's a format specifier for a double (elapsed time), but I
>>> inadvertently dropped the f  (should be .4fs, where the s is short for
>>> seconds).
>>>
>>> This was causing my program to fail, and I didn't look closely enough at
>>> that line. Now I'm golden - I think.
>>>
>>> Thanks for spotting it!
>>>
>> If you use a good modern IDE, it will warn you when the format string
>> and the arguments don't match.
> 
> 
> I'm using geany and Tiny C Compiler (Windows).  Neither one catches it 
> (I wouldn't expect Geany to).
> 

/Why/ are you using tcc?  If you were developing on a tiny or ancient 
computer, I could understand it.  But gcc is a vastly better compiler, 
especially during development.  Run it with warnings enabled - not just 
-Wall, but I'd recommend -Wextra as well, and perhaps "-pedantic" if you 
are interested in portable code, as well as specifying the standard you 
want (like "-std=gcc11" or "-std=c99").

> printf("%.4s remove %d dupes\n",elapsedtime(start),arrsize-cnt);
> 
> tcc -Wall -o rand.exe random_strings_clc_final.c
> compilation finished successfully
> 
> 
> But gcc (on MSYS2) does:
> 
> $ gcc -Wall -o rand.exe random_strings_clc_final.c
> random_strings_clc_final.c: In function ‘main’:
> random_strings_clc_final.c:132:16: warning: format ‘%s’ expects argument 
> of type ‘char *’, but argument 2 has type ‘double’ [-Wformat=]
>    132 |     printf("%.4s remove %d 
> dupes\n",elapsedtime(start),arrsize-cnt);
>        |             ~~~^                    ~~~~~~~~~~~~~~~~~~
>        |                |                    |
>        |                char *               double
>        |             %.4f
> 
> 

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

#147638

On 05/11/2019 22:24, David Brown wrote:
> On 05/11/2019 17:29, DFS wrote:
>> On 11/5/2019 11:04 AM, Malcolm McLean wrote:
>>> On Tuesday, 5 November 2019 15:52:48 UTC, DFS  wrote:
>>>> On 11/5/2019 10:45 AM, mark.bluemel@gmail.com wrote:
>>>>> On Tuesday, 5 November 2019 15:34:32 UTC, DFS  wrote:
>>>>>
>>>>>>        printf("%.4s remove %d 
>>>>>> dupes\n",elapsedtime(start),arrsize-cnt);
>>>>>
>>>>> "%.4s" is a (slightly unusual) format specifier for a string.
>>>>> It's a
>>>>> totally unsuitable format specifier for a double value, which I think
>>>>> is what elapsedtime() returns. I'd kind of expect it to fail, in some
>>>>> unpredictable manner, as the printf routine tries to treat a double as
>>>>> a pointer-to-char and disappears into some abyss or other.
>>>>
>>>>
>>>> Dude!  It's a format specifier for a double (elapsed time), but I
>>>> inadvertently dropped the f  (should be .4fs, where the s is short for
>>>> seconds).
>>>>
>>>> This was causing my program to fail, and I didn't look closely 
>>>> enough at
>>>> that line. Now I'm golden - I think.
>>>>
>>>> Thanks for spotting it!
>>>>
>>> If you use a good modern IDE, it will warn you when the format string
>>> and the arguments don't match.
>>
>>
>> I'm using geany and Tiny C Compiler (Windows).  Neither one catches it 
>> (I wouldn't expect Geany to).
>>
> 
> /Why/ are you using tcc?  If you were developing on a tiny or ancient 
> computer, I could understand it.  But gcc is a vastly better compiler, 
> especially during development.

gcc is a bit of a dog, especially with larger programs, or you are 
including some hefty headers.

You want something nippy during development. You can still run gcc with 
all its options every so often, or if stuck with some bug, or for 
production code to get the best performance.


>> But gcc (on MSYS2) does:
>>
>> $ gcc -Wall -o rand.exe random_strings_clc_final.c
>> random_strings_clc_final.c: In function ‘main’:
>> random_strings_clc_final.c:132:16: warning: format ‘%s’ expects 
>> argument of type ‘char *’, but argument 2 has type ‘double’ [-Wformat=]
>>    132 |     printf("%.4s remove %d 
>> dupes\n",elapsedtime(start),arrsize-cnt);
>>        |             ~~~^                    ~~~~~~~~~~~~~~~~~~
>>        |                |                    |
>>        |                char *               double
>>        |             %.4f
>>
>>
> 
Of course the real problem is C's old-fashioned printf system. Somehow 
mandating cumbersome tools to detect argument/format mismatches was seen 
as a better 'solution' than fixing the language.

And in many situations (like, all the ones where my "%?" idea won't 
work), the compiler can't detect the wrong format, and the program will 
give the wrong results, or crash.

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

#147641

On 06/11/2019 12:06, Bart wrote:
> On 05/11/2019 22:24, David Brown wrote:
>>
>> /Why/ are you using tcc?  If you were developing on a tiny or ancient
>> computer, I could understand it.  But gcc is a vastly better compiler,
>> especially during development.
> 
> gcc is a bit of a dog, especially with larger programs, or you are
> including some hefty headers.
> 
> You want something nippy during development.

You want to find as many issues in your code a quickly as possible 
during development.

-- 
Ian.

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

#147643

On 05/11/2019 23:31, Ian Collins wrote:
> On 06/11/2019 12:06, Bart wrote:
>> On 05/11/2019 22:24, David Brown wrote:
>>>
>>> /Why/ are you using tcc?  If you were developing on a tiny or ancient
>>> computer, I could understand it.  But gcc is a vastly better compiler,
>>> especially during development.
>>
>> gcc is a bit of a dog, especially with larger programs, or you are
>> including some hefty headers.
>>
>> You want something nippy during development.
> 
> You want to find as many issues in your code a quickly as possible 
> during development.

You also want as little distraction from non-issues as possible. I've 
been left in the dark as to whether an executable has actually been 
created or not because any 'error' message will be swamped by irrelevant 
warnings.

And there will be plenty of warnings in unfinished code.

I don't want to waste time dealing with warnings that will only be 
temporary, or I know are not relevant or not important.

If I run gcc with no options, I get fewer warnings, but it isn't 
actually that much faster.

As I said, it's a dog.

(However I'm impressed by the 'geany' editor the OP uses and which I've 
just downloaded. Not enough to use it (it doesn't have hard line stops), 
but it makes my code look good even if it has no idea what language it is!)

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

#147644

On 06/11/2019 12:43, Bart wrote:
> On 05/11/2019 23:31, Ian Collins wrote:
>> On 06/11/2019 12:06, Bart wrote:
>>> On 05/11/2019 22:24, David Brown wrote:
>>>>
>>>> /Why/ are you using tcc?  If you were developing on a tiny or ancient
>>>> computer, I could understand it.  But gcc is a vastly better compiler,
>>>> especially during development.
>>>
>>> gcc is a bit of a dog, especially with larger programs, or you are
>>> including some hefty headers.
>>>
>>> You want something nippy during development.
>>
>> You want to find as many issues in your code a quickly as possible
>> during development.
> 
> You also want as little distraction from non-issues as possible. I've
> been left in the dark as to whether an executable has actually been
> created or not because any 'error' message will be swamped by irrelevant
> warnings.

If a warning is truly irrelevant, disable it.  Otherwise fix it.

> And there will be plenty of warnings in unfinished code.

Not in mine.  Every compile is a "make test"...

> If I run gcc with no options, I get fewer warnings, but it isn't
> actually that much faster.
> 
> As I said, it's a dog.

If it is, it's a support dog.

-- 
Ian.

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

#147646

On 05/11/2019 23:54, Ian Collins wrote:
> On 06/11/2019 12:43, Bart wrote:

>> You also want as little distraction from non-issues as possible. I've
>> been left in the dark as to whether an executable has actually been
>> created or not because any 'error' message will be swamped by irrelevant
>> warnings.
> 
> If a warning is truly irrelevant, disable it.

And we're back to build-your-own-compiler. It makes for really 
snappy-looking command lines like:

C:\mcc>gcc @w -c mc.c -Wno-cast-qual -Wno-pedantic -Wno-unused-label 
-Wno-unused-variable -Wno
-unused-parameter -Wno-strict-aliasing -Wno-unused-but-set-variable 
-Wno-maybe-uninitialized -Wno-in
itialized -Wno-format-nonliteral -Wno-logical-not-parentheses ...

Which still only partly disables the warnings enabled by @w, so why 
bother at all?

Using gcc @w gives me 18,000 lines of warnings on this program. gcc by 
itself gives zero, but takes 2 seconds, a delay that doesn't sound much, 
but is very annoying and interrupts your train of thought.

tcc also gives 0 warnings, but takes only 0.1 seconds.

Which beggars the question: if gcc is going to be configured to give 
minimum warnings like tcc, but takes 20 times as long to run, and the 
generated code runs at the same speed (otherwise it will take 50 to 120 
times as long to compile), then what is the point?

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

#147648

On 06/11/2019 14:35, Bart wrote:
> On 05/11/2019 23:54, Ian Collins wrote:
>> On 06/11/2019 12:43, Bart wrote:
> 
>>> You also want as little distraction from non-issues as possible. I've
>>> been left in the dark as to whether an executable has actually been
>>> created or not because any 'error' message will be swamped by irrelevant
>>> warnings.
>>
>> If a warning is truly irrelevant, disable it.
> 
> And we're back to build-your-own-compiler. It makes for really
> snappy-looking command lines like:
> 
> C:\mcc>gcc @w -c mc.c -Wno-cast-qual -Wno-pedantic -Wno-unused-label
> -Wno-unused-variable -Wno
> -unused-parameter -Wno-strict-aliasing -Wno-unused-but-set-variable
> -Wno-maybe-uninitialized -Wno-in
> itialized -Wno-format-nonliteral -Wno-logical-not-parentheses ...

All of those are warnings we have on.  If they give you trouble, you 
have some truly messy code...

-- 
Ian.

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

#147662

On 06/11/2019 02:16, Ian Collins wrote:
> On 06/11/2019 14:35, Bart wrote:
>> On 05/11/2019 23:54, Ian Collins wrote:
>>> On 06/11/2019 12:43, Bart wrote:
>>
>>>> You also want as little distraction from non-issues as possible. I've
>>>> been left in the dark as to whether an executable has actually been
>>>> created or not because any 'error' message will be swamped by 
>>>> irrelevant
>>>> warnings.
>>>
>>> If a warning is truly irrelevant, disable it.
>>
>> And we're back to build-your-own-compiler. It makes for really
>> snappy-looking command lines like:
>>
>> C:\mcc>gcc @w -c mc.c -Wno-cast-qual -Wno-pedantic -Wno-unused-label
>> -Wno-unused-variable -Wno
>> -unused-parameter -Wno-strict-aliasing -Wno-unused-but-set-variable
>> -Wno-maybe-uninitialized -Wno-in
>> itialized -Wno-format-nonliteral -Wno-logical-not-parentheses ...
> 
> All of those are warnings we have on.  If they give you trouble, you 
> have some truly messy code...
> 

This particular file is generated C. The original source has been deemed 
to be correct and well-defined, when it goes straight to its native target.

When it has to pass through intermediate C and is subject to the 
interpretation of a fussy C compiler in combination with some particular 
permutation of dozens of possible warnings options, then yes it can 
appear messy.

But that is mainly artefacts created by the C language, the specific C 
compiler, and the chosen set of options.

However, /I/ specify the C compiler(s) and the options. And with those, 
there should be zero warnings.

(When I deal with such intermediate C in one step, my original language 
compiler will automatically invoke the C compiler (gcc, tcc or bcc) with 
the proper options.)

Of course there might things amiss in the original language that my 
compiler doesn't check, but a C compiler might (eg. unused parameters). 
I don't consider such things as errors; just something that might need 
tidying up. Or a function is not yet finished.

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

#147658

On Tuesday, 5 November 2019 23:55:07 UTC, Ian Collins  wrote:
> On 06/11/2019 12:43, Bart wrote:
> > On 05/11/2019 23:31, Ian Collins wrote:
> >>
> >> You want to find as many issues in your code a quickly as possible
> >> during development.
> > 
> > You also want as little distraction from non-issues as possible. I've
> > been left in the dark as to whether an executable has actually been
> > created or not because any 'error' message will be swamped by irrelevant
> > warnings.
> 
> If a warning is truly irrelevant, disable it.  Otherwise fix it.
> 
During development, code is often in an intermediate stage. It's known
to be incomplete, or buggy, but we still want to compile and maybe
run it. So there might be things like unreachable code, or statements
with no effect, that the compiler warns about. That's one reason why
warnings are warnings rather than errors. However we often still want
the warning, we want to know where the code is being worked on and
contains temporary statements. 

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

#147659

On 06/11/2019 10:59, Malcolm McLean wrote:
> On Tuesday, 5 November 2019 23:55:07 UTC, Ian Collins  wrote:
>> On 06/11/2019 12:43, Bart wrote:
>>> On 05/11/2019 23:31, Ian Collins wrote:
>>>>
>>>> You want to find as many issues in your code a quickly as possible
>>>> during development.
>>>
>>> You also want as little distraction from non-issues as possible. I've
>>> been left in the dark as to whether an executable has actually been
>>> created or not because any 'error' message will be swamped by irrelevant
>>> warnings.
>>
>> If a warning is truly irrelevant, disable it.  Otherwise fix it.
>>
> During development, code is often in an intermediate stage. It's known
> to be incomplete, or buggy, but we still want to compile and maybe
> run it. So there might be things like unreachable code, or statements
> with no effect, that the compiler warns about. That's one reason why
> warnings are warnings rather than errors. However we often still want
> the warning, we want to know where the code is being worked on and
> contains temporary statements. 
> 

It is also a reason why developers should use good tools, and know how
to use them.  This all smacks of "a bad workman blames his tools".  If
you don't know how to avoid or deal with the issues you have invented
here, then you should be asking for help, not making excuses.  (If you
want to ask here, I will happily give you suggestions.)

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

#147671

On Wednesday, 6 November 2019 10:35:27 UTC, David Brown  wrote:
> On 06/11/2019 10:59, Malcolm McLean wrote:
> > On Tuesday, 5 November 2019 23:55:07 UTC, Ian Collins  wrote:
> >> On 06/11/2019 12:43, Bart wrote:
> >>> On 05/11/2019 23:31, Ian Collins wrote:
> >>>>
> >>>> You want to find as many issues in your code a quickly as possible
> >>>> during development.
> >>>
> >>> You also want as little distraction from non-issues as possible. I've
> >>> been left in the dark as to whether an executable has actually been
> >>> created or not because any 'error' message will be swamped by irrelevant
> >>> warnings.
> >>
> >> If a warning is truly irrelevant, disable it.  Otherwise fix it.
> >>
> > During development, code is often in an intermediate stage. It's known
> > to be incomplete, or buggy, but we still want to compile and maybe
> > run it. So there might be things like unreachable code, or statements
> > with no effect, that the compiler warns about. That's one reason why
> > warnings are warnings rather than errors. However we often still want
> > the warning, we want to know where the code is being worked on and
> > contains temporary statements. 
> > 
> 
> It is also a reason why developers should use good tools, and know how
> to use them.  This all smacks of "a bad workman blames his tools".  If
> you don't know how to avoid or deal with the issues you have invented
> here, then you should be asking for help, not making excuses.  (If you
> want to ask here, I will happily give you suggestions.)
>
You avoid the issue by not using "treat warning as errors" for debug 
builds, only for release candidate builds, after warnings have been
removed. In fact you don't even need the flag then, because you can
see that the build is clean and there are no warnings.

Very simple process. As long as you admit that a compiler which distinguishes
between non-fatal "warnings" and fatal "errors" is a better tool than
a compiler that doesn't make such a distinction.

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web