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

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

Whaddaya think?

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

Contents

  Whaddaya think? DFS <nospam@dfs.com> - 2024-06-15 15:36 -0400
    Re: Whaddaya think? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-15 22:33 +0100
    Re: Whaddaya think? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-15 23:03 +0100
      Re: Whaddaya think? bart <bc@freeuk.com> - 2024-06-16 00:22 +0100
        Re: Whaddaya think? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-16 10:30 +0100
      Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-16 11:52 -0400
        Re: Whaddaya think? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 00:17 +0100
          Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 08:49 -0400
    Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-15 15:22 -0700
      Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-16 12:20 -0400
        Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 13:54 -0700
        Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-16 22:41 -0400
          Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-16 22:45 -0700
          Re: Whaddaya think? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-17 07:39 +0000
            Re: Whaddaya think? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-17 01:22 -0700
            Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 09:50 -0400
              Re: Whaddaya think? Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-17 16:23 +0100
                Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-17 18:46 +0200
                Re: Whaddaya think? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-22 22:14 +0000
                  Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 17:10 -0700
                  Re: Whaddaya think? Phil Carmody <pc+usenet@asdf.org> - 2024-06-23 11:20 +0300
            Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 00:19 -0700
              Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 03:10 -0700
                Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 17:24 -0700
                  Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 17:55 -0700
                    Re: Whaddaya think? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-19 01:58 +0000
          Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 08:50 -0400
            Re: Whaddaya think? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 15:41 +0100
              Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-18 08:12 +0200
                Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 03:07 -0700
        Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 00:30 -0400
    Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 01:56 +0300
      Re: Whaddaya think? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 03:26 +0000
        Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 05:41 +0200
          Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-15 21:17 -0700
            Re: Whaddaya think? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 04:41 +0000
            Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 06:44 +0200
              Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-16 11:09 -0400
                Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-16 17:56 +0200
                  Re: Whaddaya think? bart <bc@freeuk.com> - 2024-06-16 18:14 +0100
                    Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-17 14:44 +0200
                  Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 09:52 -0400
          Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 06:51 +0200
            Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-15 22:21 -0700
              Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 07:41 +0200
                Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-15 22:49 -0700
                  Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 11:29 +0200
                    Re: Whaddaya think? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-16 16:04 +0100
                      Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 17:13 +0200
                    Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 13:32 -0700
                      Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 07:41 +0200
                        Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 23:20 -0700
                          Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 09:16 +0200
                            Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 09:38 -0400
                              Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 16:17 -0700
                              Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-18 07:09 +0200
                                Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:25 -0400
                                Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 02:57 -0700
                            Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 16:15 -0700
                              Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-18 08:02 +0200
                              Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 19:07 -0700
                                Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-19 09:50 +0200
                                  Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 13:13 -0700
                        Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 02:21 -0400
                          Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 09:22 +0200
                Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 11:11 +0300
                  Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 11:07 +0200
                    Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 12:38 +0300
                      Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 12:03 +0200
                        Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 14:31 +0300
                          Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 17:37 +0200
                            Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-17 00:45 +0300
                Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 17:06 -0700
                  Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-16 22:40 -0700
                    Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 07:52 +0200
                      Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 09:45 -0400
                        Re: Whaddaya think? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-17 13:16 -0700
                          Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-17 17:07 -0400
                            Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 15:48 -0700
                            Re: Whaddaya think? scott@slp53.sl.home (Scott Lurndal) - 2024-06-17 22:48 +0000
                        Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 15:44 -0700
                          Re: Whaddaya think? David Brown <david.brown@hesbynett.no> - 2024-06-18 15:00 +0200
                        Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-18 06:57 +0200
                      Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 00:25 -0700
                    Re: Whaddaya think? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 02:38 -0400
                      Re: Whaddaya think? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 17:01 -0700
                  Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 07:48 +0200
                    Re: Whaddaya think? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 23:29 -0700
                      Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 09:35 +0200
          Re: Whaddaya think? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-16 08:19 +0100
          Re: Whaddaya think? Michael S <already5chosen@yahoo.com> - 2024-06-16 10:44 +0300
            Re: Whaddaya think? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-16 11:13 +0200
      Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-16 11:03 -0400
    Re: Whaddaya think? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-16 15:52 +0000
      Re: Whaddaya think? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-16 17:17 +0100
      Re: Whaddaya think? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 08:06 +0000
      Re: Whaddaya think? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-25 17:37 +0000
        Re: Whaddaya think? DFS <nospam@dfs.com> - 2024-06-25 14:09 -0400
          Re: Whaddaya think? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-25 18:11 +0000

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

#385982 — Whaddaya think?

I want to read numbers in from a file, say:

47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245 
294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178 
108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79 
193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297 
15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291


This code:
1 opens the file
2 fscanf thru the file to count the number of data points
3 allocate memory
4 rewind and fscanf again to add the data to the int array


Any issues with this method?

Any 'better' way?

Thanks


----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {

	int N=0, i=0, j=0;
	int *nums;
	
	FILE* datafile = fopen(argv[1], "r");
	while(fscanf(datafile, "%d", &j) != EOF){
		N++;
	}
	
	nums = calloc(N, sizeof(int));
	rewind(datafile);
	while(fscanf(datafile, "%d", &j) != EOF){
		nums[i++] = j;
	}
	fclose (datafile);
	printf("\n");
	
	for(i=0;i<N;i++) {
		printf("%d. %d\n", i+1, nums[i]);
	}
	printf("\n");
	free(nums);
	return(0);
				
}
----------------------------------------------------------

[toc] | [next] | [standalone]

#385986

On 15/06/2024 20:36, DFS wrote:
> I want to read numbers in from a file, say:
> 
> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245 
> 294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178 
> 108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79 
> 193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297 
> 15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
> 
> 
> This code:
> 1 opens the file
> 2 fscanf thru the file to count the number of data points
> 3 allocate memory
> 4 rewind and fscanf again to add the data to the int array
> 
> 
> Any issues with this method?
> 
> Any 'better' way?
> 
> Thanks
> 
> 
> ----------------------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char *argv[]) {
> 
>      int N=0, i=0, j=0;
>      int *nums;
> 
>      FILE* datafile = fopen(argv[1], "r");
>      while(fscanf(datafile, "%d", &j) != EOF){
>          N++;
>      }
> 
>      nums = calloc(N, sizeof(int));
>      rewind(datafile);
>      while(fscanf(datafile, "%d", &j) != EOF){
>          nums[i++] = j;
>      }
>      fclose (datafile);
>      printf("\n");
> 
>      for(i=0;i<N;i++) {
>          printf("%d. %d\n", i+1, nums[i]);
>      }
>      printf("\n");
>      free(nums);
>      return(0);
> 
> }
> ----------------------------------------------------------
> 
> 
Some files can't be rewound. Whilst C doesn't have dynamic arrays, 
languages tha do suooort then usually build them on top of the C-linked 
realloc() function. It's redious, but not hard to do.
-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

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

#385987

DFS <nospam@dfs.com> writes:

> I want to read numbers in from a file, say:
>
> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245 294
> 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178 108 152
> 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79 193 282
> 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297 15 141 232
> 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
>
>
> This code:
> 1 opens the file
> 2 fscanf thru the file to count the number of data points
> 3 allocate memory
> 4 rewind and fscanf again to add the data to the int array
>
> Any issues with this method?

There are two issues: (1) you end up with a program that can't be
"piped" to (because the input can't be rewound), and (2) the file might
change between counting and reading.  How much either matters will
depend on the context.  I like piping to programs so (1) would bother
me.

> Any 'better' way?

I'd allocate the array on the fly.  It's one of those things that, once
you've done it, becomes a stock bit of coding.  In fact, you can write a
simple dynamic array module, and use it again and again.
> ----------------------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char *argv[]) {
>
> 	int N=0, i=0, j=0;
> 	int *nums;
> 	
> 	FILE* datafile = fopen(argv[1], "r");
> 	while(fscanf(datafile, "%d", &j) != EOF){

It's always better to loop while fscanf succeeds rather than trying to
handle all the errors.  You might not care about case where this loop
fails, but it's just better to get into the right habit:

  while (fscanf(datafile, "%d", &j) == 1) ...

> 	nums = calloc(N, sizeof(int));

The cost is low, but there's no need to use calloc here as you are going
to assign exactly N locations.

> 	rewind(datafile);
> 	while(fscanf(datafile, "%d", &j) != EOF){
> 		nums[i++] = j;
> 	}

As above, though I'd read into &nums[i] directly.

> 	fclose (datafile);
> 	printf("\n");
> 	
> 	for(i=0;i<N;i++) {
> 		printf("%d. %d\n", i+1, nums[i]);
> 	}
> 	printf("\n");
> 	free(nums);
> 	return(0);

Because I have acquired the habit, I'd also check for errors,
particularly on argc, fopen and malloc.

> 				
> }
> ----------------------------------------------------------

-- 
Ben.

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

#385995

On 15/06/2024 23:03, Ben Bacarisse wrote:
> DFS <nospam@dfs.com> writes:
> 
>> I want to read numbers in from a file, say:
>>
>> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245 294
>> 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178 108 152
>> 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79 193 282
>> 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297 15 141 232
>> 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
>>
>>
>> This code:
>> 1 opens the file
>> 2 fscanf thru the file to count the number of data points
>> 3 allocate memory
>> 4 rewind and fscanf again to add the data to the int array
>>
>> Any issues with this method?
> 
> There are two issues: (1) you end up with a program that can't be
> "piped" to (because the input can't be rewound), and (2) the file might
> change between counting and reading.

It might change even while you're reading it once.

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

#386015

bart <bc@freeuk.com> writes:

> On 15/06/2024 23:03, Ben Bacarisse wrote:
>> DFS <nospam@dfs.com> writes:
>> 
>>> I want to read numbers in from a file, say:
>>>
>>> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245 294
>>> 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178 108 152
>>> 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79 193 282
>>> 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297 15 141 232
>>> 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
>>>
>>>
>>> This code:
>>> 1 opens the file
>>> 2 fscanf thru the file to count the number of data points
>>> 3 allocate memory
>>> 4 rewind and fscanf again to add the data to the int array
>>>
>>> Any issues with this method?
>> There are two issues: (1) you end up with a program that can't be
>> "piped" to (because the input can't be rewound), and (2) the file might
>> change between counting and reading.
>
> It might change even while you're reading it once.

Your program will see the data it sees -- in that sense the file does
not change.  When there are two (or more) phases to the input, your
program has to handle some new error conditions that are logically
avoided by just reading what's available (even if, to some outside
observer, it's "changing").

-- 
Ben.

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

#386030

On 6/15/2024 6:03 PM, Ben Bacarisse wrote:
> DFS <nospam@dfs.com> writes:
> 
>> I want to read numbers in from a file, say:
>>
>> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118 245 294
>> 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144 245 178 108 152
>> 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195 32 4 54 79 193 282
>> 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55 259 137 297 15 141 232
>> 259 285 300 153 16 4 207 95 197 188 267 164 195 7 104 47 291
>>
>>
>> This code:
>> 1 opens the file
>> 2 fscanf thru the file to count the number of data points
>> 3 allocate memory
>> 4 rewind and fscanf again to add the data to the int array
>>
>> Any issues with this method?
> 
> There are two issues: (1) you end up with a program that can't be
> "piped" to (because the input can't be rewound), and (2) the file might
> change between counting and reading.  How much either matters will
> depend on the context.  I like piping to programs so (1) would bother
> me.
> 
>> Any 'better' way?
> 
> I'd allocate the array on the fly.  It's one of those things that, once
> you've done it, becomes a stock bit of coding.  In fact, you can write a
> simple dynamic array module, and use it again and again.
>> ----------------------------------------------------------
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int argc, char *argv[]) {
>>
>> 	int N=0, i=0, j=0;
>> 	int *nums;
>> 	
>> 	FILE* datafile = fopen(argv[1], "r");
>> 	while(fscanf(datafile, "%d", &j) != EOF){
> 
> It's always better to loop while fscanf succeeds rather than trying to
> handle all the errors.  You might not care about case where this loop
> fails, but it's just better to get into the right habit:
> 
>    while (fscanf(datafile, "%d", &j) == 1) ...
> 
>> 	nums = calloc(N, sizeof(int));
> 
> The cost is low, but there's no need to use calloc here as you are going
> to assign exactly N locations.
> 
>> 	rewind(datafile);
>> 	while(fscanf(datafile, "%d", &j) != EOF){
>> 		nums[i++] = j;
>> 	}
> 
> As above, though I'd read into &nums[i] directly.
> 
>> 	fclose (datafile);
>> 	printf("\n");
>> 	
>> 	for(i=0;i<N;i++) {
>> 		printf("%d. %d\n", i+1, nums[i]);
>> 	}
>> 	printf("\n");
>> 	free(nums);
>> 	return(0);
> 
> Because I have acquired the habit, I'd also check for errors,
> particularly on argc, fopen and malloc.
> 
>> 				
>> }
>> ----------------------------------------------------------

Thanks for the tips.

I'm not into error checking on my personal code.  But I am into brief 
and efficient.

New effort
* dropped 2 variables
* allocate 'on the fly'
* one fscanf thru the file
* 4 less lines of code

----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {

	int N=0;
	int *nums = malloc(2 * sizeof(int));
	
	FILE* datafile = fopen(argv[1], "r");
	while(fscanf(datafile, "%d", &nums[N++]) == 1){
		nums = realloc(nums, (N+1) * sizeof(int));
	}
	fclose (datafile);
	
	N--;
	for(int i=0;i<N;i++) {
		printf("%d.%d  ", i+1, nums[i]);
	}	
	free(nums);
	
	printf("\n");
	return 0;
				
}
----------------------------------------------------------




original 19 lines not incl close brackets
----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {

     int N=0, i=0, j=0;
     int *nums;

     FILE* datafile = fopen(argv[1], "r");
     while(fscanf(datafile, "%d", &j) != EOF){
         N++;
     }

     nums = calloc(N, sizeof(int));
     rewind(datafile);
     while(fscanf(datafile, "%d", &j) != EOF){
         nums[i++] = j;
     }
     fclose (datafile);
     printf("\n");

     for(i=0;i<N;i++) {
         printf("%d. %d\n", i+1, nums[i]);
     }
     printf("\n");
     free(nums);
     return(0);

}
----------------------------------------------------------

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

#386041

DFS <nospam@dfs.com> writes:

> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char *argv[]) {
>
> 	int N=0;
> 	int *nums = malloc(2 * sizeof(int));
> 	
> 	FILE* datafile = fopen(argv[1], "r");
> 	while(fscanf(datafile, "%d", &nums[N++]) == 1){
> 		nums = realloc(nums, (N+1) * sizeof(int));
> 	}
> 	fclose (datafile);
> 	
> 	N--;

This N-- is a bit "tricksy".  Better to increment in the realloc (or the
while body) so it only happens when an int has been read.

-- 
Ben.

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

#386085

On 6/16/2024 7:17 PM, Ben Bacarisse wrote:
> DFS <nospam@dfs.com> writes:
> 
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int argc, char *argv[]) {
>>
>> 	int N=0;
>> 	int *nums = malloc(2 * sizeof(int));
>> 	
>> 	FILE* datafile = fopen(argv[1], "r");
>> 	while(fscanf(datafile, "%d", &nums[N++]) == 1){
>> 		nums = realloc(nums, (N+1) * sizeof(int));
>> 	}
>> 	fclose (datafile);
>> 	
>> 	N--;
> 
> This N-- is a bit "tricksy".  Better to increment in the realloc (or the
> while body) so it only happens when an int has been read.

I don't like it either, but I've already spent about 3 full days on the 
whole stats program, and life's too short.  N has to be the number of 
data points, because it's used throughout the rest of the program.

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

#385989

DFS <nospam@dfs.com> writes:
> I want to read numbers in from a file, say:
>
> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118
> 245 294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144
> 245 178 108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195
> 32 4 54 79 193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55
> 259 137 297 15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195
> 7 104 47 291
>
>
> This code:
> 1 opens the file
> 2 fscanf thru the file to count the number of data points
> 3 allocate memory
> 4 rewind and fscanf again to add the data to the int array
>
>
> Any issues with this method?
>
> Any 'better' way?
>
> Thanks

In a quick test, your code compiles without errors and runs correctly
with your input.  I do get a warning about argc being unused, which you
should address.

> ----------------------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char *argv[]) {
>
> 	int N=0, i=0, j=0;

The usual convention is to use all-caps for macro names.  Calling your
variable N is not a real problem, but could be slightly confusing.

N is the number of integers in the input.  i is an index.  j is a value
read from the file.  That's not at all clear from the names.

I suggest using longer and more descriptive names in lower case.
"N" could be "count".  "i" is fine for an index, but "j" could be
"value".

Consider using size_t rather than int for the count and index.  That's
mostly a style point; it's not going to make any practical difference
unless you have at least INT_MAX elements.

> 	int *nums;
> 	
> 	FILE* datafile = fopen(argv[1], "r");

Undefined behavior if no argument was provided, i.e., argc < 1.

> 	while(fscanf(datafile, "%d", &j) != EOF){

Numeric input with the *scanf functions has undefined behavior if the
scanned value is outside the range of the target type.  For example, if
the input contains "99999999999999999999999999999999999999999999999999",
arbitrary bad things could happen.  (Most likely it will just store some
incorrect value in j, with no indication that there was an error.)

strtol is trickier to use, but you can detect errors.

fscanf returns EOF on reaching the end of the file or on a read error,
and that's the only condition you check.  It returns the number of items
scanned.  If the input doesn't contain a string that can be interpreted
as an integer, fscanf will return 0, and you'll be stuck in an infinite
loop.  `while (fscanf(...) == 1)` is more robust, but it doesn't
distinguish between a read error and bad data.  It's up to you how and
whether to distinguish among different kinds of errors.

Your sample input consists of decimal integers with no sign.  Decide
whether you want to hande "-123" or "+123".  (fscanf will do so; so will
strtol.)

> 		N++;
> 	}
> 	
> 	nums = calloc(N, sizeof(int));

Consider using `sizeof *nums` rather than `sizeof(int)`.  That way you
don't have to change the type in two places if the element type changes.

You'll be updating all the elements of the nums array, so there's not
much point in zeroing it.  If you use malloc:

    nums = malloc(N * sizeof *nums);

Whether you use calloc() or malloc(), you should check the return
value.  If it returns a null pointer, it means the allocation failed.
Aborting the program is probably a good way to handle it.

(There are complications on Linux-based systems which I won't get into
here.  Google "OOM killer" and "overcommit" for details.)

> 	rewind(datafile);

This can fail if the input file is not seekable.  For example, on a
Linux-based system you could do something like:
    ./your_program /dev/stdin < file
Perhaps that's an acceptable restriction, but be aware of it.

> 	while(fscanf(datafile, "%d", &j) != EOF){

Again, UB for out of range values.

It's not guaranteed that you'll get the same data the second time you
read the file; some other process could modify it.  This might not be
worth worrying about.

> 		nums[i++] = j;
> 	}
> 	fclose (datafile);
> 	printf("\n");

You haven't produced any output yet; why print a blank line?  (Of course
you can if you want to.)

> 	for(i=0;i<N;i++) {
> 		printf("%d. %d\n", i+1, nums[i]);
> 	}
> 	printf("\n");
> 	free(nums);
> 	return(0);

A minor style point: a return statement doesn't require parentheses.
IMHO using parentheses make it look too much like a function call.  I'd
write `return 0;`, or more likely I'd just omit it, since falling off
the end of main does an implicit `return 0;` (starting in C99).

> }

A method that doesn't require rescanning the input file is to initially
allocate some reasonable amount of memory, then use realloc() to
expand the array as needed.  Doubling the array size is probably
reasonable.  It will consume more memory than a single allocation.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#386033

On 6/15/2024 6:22 PM, Keith Thompson wrote:
> DFS <nospam@dfs.com> writes:
>> I want to read numbers in from a file, say:
>>
>> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118
>> 245 294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144
>> 245 178 108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195
>> 32 4 54 79 193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55
>> 259 137 297 15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195
>> 7 104 47 291
>>
>>
>> This code:
>> 1 opens the file
>> 2 fscanf thru the file to count the number of data points
>> 3 allocate memory
>> 4 rewind and fscanf again to add the data to the int array
>>
>>
>> Any issues with this method?
>>
>> Any 'better' way?
>>
>> Thanks
> 
> In a quick test, your code compiles without errors and runs correctly
> with your input.  I do get a warning about argc being unused, which you
> should address.

-Wall doesn't warn about that, but -Wall -Wextra does.

In the bigger program of which this is a part, argc IS used.


>> ----------------------------------------------------------
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int argc, char *argv[]) {
>>
>> 	int N=0, i=0, j=0;
> 
> The usual convention is to use all-caps for macro names.  Calling your
> variable N is not a real problem, but could be slightly confusing.
> 
> N is the number of integers in the input.  i is an index.  j is a value
> read from the file.  That's not at all clear from the names.
> 
> I suggest using longer and more descriptive names in lower case.
> "N" could be "count".  "i" is fine for an index, but "j" could be
> "value".


N is used in statistics, and this is a stats program.



> Consider using size_t rather than int for the count and index.  That's
> mostly a style point; it's not going to make any practical difference
> unless you have at least INT_MAX elements.
> 
>> 	int *nums;
>> 	
>> 	FILE* datafile = fopen(argv[1], "r");
> 
> Undefined behavior if no argument was provided, i.e., argc < 1.
> 
>> 	while(fscanf(datafile, "%d", &j) != EOF){
> 
> Numeric input with the *scanf functions has undefined behavior if the
> scanned value is outside the range of the target type.  For example, if
> the input contains "99999999999999999999999999999999999999999999999999",
> arbitrary bad things could happen.  (Most likely it will just store some
> incorrect value in j, with no indication that there was an error.)
> 
> strtol is trickier to use, but you can detect errors.
> 
> fscanf returns EOF on reaching the end of the file or on a read error,
> and that's the only condition you check.  It returns the number of items
> scanned.  If the input doesn't contain a string that can be interpreted
> as an integer, fscanf will return 0, and you'll be stuck in an infinite
> loop.  `while (fscanf(...) == 1)` is more robust, but it doesn't
> distinguish between a read error and bad data.  It's up to you how and
> whether to distinguish among different kinds of errors.
> 
> Your sample input consists of decimal integers with no sign.  Decide
> whether you want to hande "-123" or "+123".  (fscanf will do so; so will
> strtol.)

A change I might make down the road is to process positive floats.  For 
now it's just positive ints.


>> 		N++;
>> 	}
>> 	
>> 	nums = calloc(N, sizeof(int));
> 
> Consider using `sizeof *nums` rather than `sizeof(int)`.  That way you
> don't have to change the type in two places if the element type changes.
> 
> You'll be updating all the elements of the nums array, so there's not
> much point in zeroing it.  If you use malloc:
> 
>      nums = malloc(N * sizeof *nums);
> 
> Whether you use calloc() or malloc(), you should check the return
> value.  If it returns a null pointer, it means the allocation failed.
> Aborting the program is probably a good way to handle it.

I usually don't do error checking on my personal code.


> (There are complications on Linux-based systems which I won't get into
> here.  Google "OOM killer" and "overcommit" for details.)
> 
>> 	rewind(datafile);
> 
> This can fail if the input file is not seekable.  For example, on a
> Linux-based system you could do something like:
>      ./your_program /dev/stdin < file
> Perhaps that's an acceptable restriction, but be aware of it.
> 
>> 	while(fscanf(datafile, "%d", &j) != EOF){
> 
> Again, UB for out of range values.
> 
> It's not guaranteed that you'll get the same data the second time you
> read the file; some other process could modify it.  This might not be
> worth worrying about.

I updated the code to do one fscanf() thru the file.

I looked for an easy way to lock it while reading, but as I understand 
flock() it only places an 'advisory lock' on the file, and other 
processes are still free to modify it.


>> 		nums[i++] = j;
>> 	}
>> 	fclose (datafile);
>> 	printf("\n");
> 
> You haven't produced any output yet; why print a blank line?  (Of course
> you can if you want to.)
> 
>> 	for(i=0;i<N;i++) {
>> 		printf("%d. %d\n", i+1, nums[i]);
>> 	}
>> 	printf("\n");
>> 	free(nums);
>> 	return(0);
> 
> A minor style point: a return statement doesn't require parentheses.
> IMHO using parentheses make it look too much like a function call.  I'd
> write `return 0;`, or more likely I'd just omit it, since falling off
> the end of main does an implicit `return 0;` (starting in C99).

Can't omit it.  It's required by my brain.


>> }
> 
> A method that doesn't require rescanning the input file is to initially
> allocate some reasonable amount of memory, then use realloc() to
> expand the array as needed.  Doubling the array size is probably
> reasonable.  It will consume more memory than a single allocation.

Done in a way, as you'll see below.


Thanks for the thorough analysis and good tips.


Updated
* dropped 2 variable declarations
* allocate 'on the fly'
* one fscanf thru the file
* 4 less lines of code (not incl brackets)

----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {

     int N=0;
     int *nums = malloc(2 * sizeof(int));

     FILE* datafile = fopen(argv[1], "r");
     while(fscanf(datafile, "%d", &nums[N++]) == 1){
         nums = realloc(nums, (N+1) * sizeof(int));
     }
     fclose (datafile);

     N--;
     for(int i=0;i<N;i++) {
         printf("%d.%d  ", i+1, nums[i]);
     }
     free(nums);

     printf("\n");
     return 0;

}
----------------------------------------------------------

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

#386039

DFS <nospam@dfs.com> writes:
> On 6/15/2024 6:22 PM, Keith Thompson wrote:
>> DFS <nospam@dfs.com> writes:
>>> I want to read numbers in from a file, say:
>>>
>>> 47 185 99 74 202 118 78 203 264 207 19 17 34 167 148 54 297 271 118
>>> 245 294 188 140 134 251 188 236 160 48 189 228 94 74 27 168 275 144
>>> 245 178 108 152 197 125 185 63 272 239 60 242 56 4 235 244 144 69 195
>>> 32 4 54 79 193 282 173 267 8 40 241 152 285 119 259 136 15 83 21 78 55
>>> 259 137 297 15 141 232 259 285 300 153 16 4 207 95 197 188 267 164 195
>>> 7 104 47 291
>>>
>>>
>>> This code:
>>> 1 opens the file
>>> 2 fscanf thru the file to count the number of data points
>>> 3 allocate memory
>>> 4 rewind and fscanf again to add the data to the int array
>>>
>>>
>>> Any issues with this method?
>>>
>>> Any 'better' way?
>>>
>>> Thanks
>> In a quick test, your code compiles without errors and runs
>> correctly
>> with your input.  I do get a warning about argc being unused, which you
>> should address.
>
> -Wall doesn't warn about that, but -Wall -Wextra does.

True (at least for gcc).

> In the bigger program of which this is a part, argc IS used.

I suggest that argc *should* have been used in this program.

>>> ----------------------------------------------------------
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main(int argc, char *argv[]) {
>>>
>>> 	int N=0, i=0, j=0;
>> The usual convention is to use all-caps for macro names.  Calling
>> your
>> variable N is not a real problem, but could be slightly confusing.
>> N is the number of integers in the input.  i is an index.  j is a
>> value
>> read from the file.  That's not at all clear from the names.
>> I suggest using longer and more descriptive names in lower case.
>> "N" could be "count".  "i" is fine for an index, but "j" could be
>> "value".
>
>
> N is used in statistics, and this is a stats program.

OK, using the names i and j suggests they're used similarly when they're
not.

[...]

> I looked for an easy way to lock it while reading, but as I understand
> flock() it only places an 'advisory lock' on the file, and other 
> processes are still free to modify it.

Locking the file probably isn't worth the effort.  If I were doing this
kind of thing, I'd just keep in the back of my mind that if some other
process modifies the file while my program is running, bad things can
happen.  For something that's going to be used in production, more care
is appropriate.

[...]

>> A minor style point: a return statement doesn't require parentheses.
>> IMHO using parentheses make it look too much like a function call.  I'd
>> write `return 0;`, or more likely I'd just omit it, since falling off
>> the end of main does an implicit `return 0;` (starting in C99).
>
> Can't omit it.  It's required by my brain.

OK, that's harmless -- but be prepared to see the "return 0;" omitted in
code written by other people.

>
>>> }
>> A method that doesn't require rescanning the input file is to
>> initially
>> allocate some reasonable amount of memory, then use realloc() to
>> expand the array as needed.  Doubling the array size is probably
>> reasonable.  It will consume more memory than a single allocation.
>
> Done in a way, as you'll see below.
>
>
> Thanks for the thorough analysis and good tips.
>
>
> Updated
> * dropped 2 variable declarations
> * allocate 'on the fly'
> * one fscanf thru the file
> * 4 less lines of code (not incl brackets)
>
> ----------------------------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char *argv[]) {
>
>     int N=0;
>     int *nums = malloc(2 * sizeof(int));

Again, I really recommend

    int *nums = malloc(2 * sizeof *nums);

>     FILE* datafile = fopen(argv[1], "r");

Undefined behavior if the program is invoked with no arguments.
No check whether fopen succeeded.

>     while(fscanf(datafile, "%d", &nums[N++]) == 1){

I've already discussed the problems of using fscanf for numeric input.

>         nums = realloc(nums, (N+1) * sizeof(int));

I'd think about moving the increment of N so that I don't have to use
"N+1" in realloc or add "N--;" at the end.  I haven't taken the time to
work out the details, but I think this can be done more cleanly.

Calling realloc() every time could be wasteful.  (On my system, realloc
reallocates at about 25 bytes and not again until about 128 kbytes, but
don't rely on that.)  A common scheme is to call realloc() to double the
buffer size as needed.  This requires keep track of the size of the
buffer and the number of elements used separately.  But for a
quick-and-dirty demo, calling realloc() every time isn't too bad.

>     }
>     fclose (datafile);
>
>     N--;
>     for(int i=0;i<N;i++) {
>         printf("%d.%d  ", i+1, nums[i]);
>     }
>     free(nums);
>
>     printf("\n");
>     return 0;
>
> }
> ----------------------------------------------------------

You changed the output format.  Your original program printed each
number on line line (with extra blank lines at the top and bottom for
some reason); this program prints all the numbers on a single line.
Neither is right or wrong, but consistency is nice -- and very long
lines can cause problems in looking at the output.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#386045

On 6/16/24 12:20, DFS wrote:
> On 6/15/2024 6:22 PM, Keith Thompson wrote:
>> DFS <nospam@dfs.com> writes:
...
>>> 	return(0);
>>
>> A minor style point: a return statement doesn't require parentheses.
>> IMHO using parentheses make it look too much like a function call.  I'd
>> write `return 0;`, or more likely I'd just omit it, since falling off
>> the end of main does an implicit `return 0;` (starting in C99).
> 
> Can't omit it.  It's required by my brain.

The parentheses you're putting in are completely unrelated to the use of
parentheses in _Generic(), function calls, compound literals,
sizeof(type name), alignof(), _BitInt(), _Atomic(), typeof(),
typeof_unqual(), alignas(), function declarators, static_assert(), if(),
switch(for(), while(), do ... while(), function-like macro definitions
and invocations or cast expressions. In all of those cases, the
parentheses are part of the grammar.

The parentheses that you put in return(0) serve only for grouping
purpose. They are semantically equivalent to the parentheses in "i =
(0);"; they are just as legal, and just as pointless.

If your brain doesn't immediately understand why what I said above is
true, I recommend retraining it.

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

#386051

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 6/16/24 12:20, DFS wrote:
>
>> On 6/15/2024 6:22 PM, Keith Thompson wrote:
>>
>>> DFS <nospam@dfs.com> writes:
>
> ...
>
>>>> 	return(0);
>>>
>>> A minor style point:  a return statement doesn't require parentheses.
>>> IMHO using parentheses make it look too much like a function call.  I'd
>>> write `return 0;`, or more likely I'd just omit it, since falling off
>>> the end of main does an implicit `return 0;` (starting in C99).
>>
>> Can't omit it.  It's required by my brain.
>
> The parentheses you're putting in are completely unrelated to the use of
> parentheses in _Generic(), function calls, compound literals,
> sizeof(type name), alignof(), _BitInt(), _Atomic(), typeof(),
> typeof_unqual(), alignas(), function declarators, static_assert(), if(),
> switch(for(), while(), do ... while(), function-like macro definitions
> and invocations or cast expressions.  In all of those cases, the
> parentheses are part of the grammar.  [...]

I'm pretty sure the "it" in "Can't omit it" was meant to refer
to having the return statement, not to the parentheses.

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

#386065

On 2024-06-17, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 6/16/24 12:20, DFS wrote:
>> On 6/15/2024 6:22 PM, Keith Thompson wrote:
>>> DFS <nospam@dfs.com> writes:
> ...
>>>> 	return(0);
>>>
>>> A minor style point: a return statement doesn't require parentheses.
>>> IMHO using parentheses make it look too much like a function call.  I'd
>>> write `return 0;`, or more likely I'd just omit it, since falling off
>>> the end of main does an implicit `return 0;` (starting in C99).
>> 
>> Can't omit it.  It's required by my brain.

I think DFS might mean that they find themselves unable to omit the
unnecessary return 0 statement entirely.

I also hate it; I feel that the implicit return 0 in main is a
misfeature that was added due to caving in to bad programmers.

Making int main(void) { } correct is like legalizing weed.
Potheads are still potheads. Since I'm not one, I write a
return statement in main.

> The parentheses you're putting in are completely unrelated to the use of
> parentheses in _Generic(), function calls, compound literals,
> sizeof(type name), alignof(), _BitInt(), _Atomic(), typeof(),
> typeof_unqual(), alignas(), function declarators, static_assert(), if(),
> switch(for(), while(), do ... while(), function-like macro definitions
> and invocations or cast expressions. In all of those cases, the
> parentheses are part of the grammar.

Speaking of while, the do/while construct does not require parentheses
in order to disambiguate anything, since it has a mandatory semicolon.
Yet, it still has them.

There would be no issue with this grammar:

  iteration_statement := 'do' statement 'while' expression ';'

the fragment "'while' expression ';'" is exactly like
"'return' expression ';'".

Obviously, the parentheses are there for consistency with the
top-testing while loop.

It seems that in some people's eyes, the same consistency should extend
to the return statement.

More widespread than that is a practice of always using parentheses
around the argument of sizeof, even if it's an expression and not
a type.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#386067

On 6/17/2024 12:39 AM, Kaz Kylheku wrote:
> On 2024-06-17, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 6/16/24 12:20, DFS wrote:
>>> On 6/15/2024 6:22 PM, Keith Thompson wrote:
>>>> DFS <nospam@dfs.com> writes:
>> ...
>>>>> 	return(0);
>>>>
>>>> A minor style point: a return statement doesn't require parentheses.
>>>> IMHO using parentheses make it look too much like a function call.  I'd
>>>> write `return 0;`, or more likely I'd just omit it, since falling off
>>>> the end of main does an implicit `return 0;` (starting in C99).
>>>
>>> Can't omit it.  It's required by my brain.
> 
> I think DFS might mean that they find themselves unable to omit the
> unnecessary return 0 statement entirely.
> 
> I also hate it; I feel that the implicit return 0 in main is a
> misfeature that was added due to caving in to bad programmers.
> 
> Making int main(void) { } correct is like legalizing weed.
> Potheads are still potheads. Since I'm not one, I write a
> return statement in main.
[...]

Indeed! Toke, Toke...

Peter Tosh - Legalize It (Audio)

https://youtu.be/6cIePqdz03A

lol. :^)

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

#386094

On 6/17/2024 3:39 AM, Kaz Kylheku wrote:

> I think DFS might mean that they find themselves 

he finds himself


> unable to omit the unnecessary return 0 statement entirely.

yes

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

#386104

On 17/06/2024 14:50, DFS wrote:
> On 6/17/2024 3:39 AM, Kaz Kylheku wrote:
> 
>> I think DFS might mean that they find themselves 
> 
> he finds himself
> 
> 
>> unable to omit the unnecessary return 0 statement entirely.
> 
> yes
> 
> 

If a function is defined to return an int, then you should return one.

Anything else is just lazy/sloppy.  Just because main allows it as a 
special case doesn't mean it's a good idea.

I mean: it's really not much extra to type.

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

#386109

On 17/06/2024 17:23, Richard Harnden wrote:
> On 17/06/2024 14:50, DFS wrote:
>> On 6/17/2024 3:39 AM, Kaz Kylheku wrote:
>>
>>> I think DFS might mean that they find themselves 
>>
>> he finds himself
>>
>>
>>> unable to omit the unnecessary return 0 statement entirely.
>>
>> yes
>>
>>
> 
> If a function is defined to return an int, then you should return one.
> 
> Anything else is just lazy/sloppy.  Just because main allows it as a 
> special case doesn't mean it's a good idea.
> 
> I mean: it's really not much extra to type.

There's nothing wrong with ending your "main" with "return 0;".  What 
Keith said was that it is unnecessary, that using parenthesis in the 
form "return(0);" looks like like a function call and is considered poor 
style by many people, and that it is useful to know that when "main" 
exists without an explicit returned value, it does so as though it had 
exited with "return 0;".  (And in another branch, he said the return 
type for "main" on hosted C systems should be "int".)

These are all true statements.

If you prefer to end "main" with "return 0;", that's absolutely fine - 
but it is /not/ lazy or sloppy to omit it.

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

#386363

On 2024-06-17, Richard Harnden <richard.nospam@gmail.invalid> wrote:
> On 17/06/2024 14:50, DFS wrote:
>> On 6/17/2024 3:39 AM, Kaz Kylheku wrote:
>> 
>>> I think DFS might mean that they find themselves 
>> 
>> he finds himself
>> 
>> 
>>> unable to omit the unnecessary return 0 statement entirely.
>> 
>> yes
>> 
>> 
>
> If a function is defined to return an int, then you should return one.
>
> Anything else is just lazy/sloppy.  Just because main allows it as a 
> special case doesn't mean it's a good idea.
>
> I mean: it's really not much extra to type.

The misfeature of missing return being success was, I believe, not
intended to make programs shorter. It was intendeda to correct the
random termination statuses of countless numbers of programs in a single
stroke.

Deliberately relying on this in a new program is like relying ona a
diaper. If you're of intermediate age, you don't do this.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#386370

Kaz Kylheku <643-408-1753@kylheku.com> writes:
[...]
> The misfeature of missing return being success was, I believe, not
> intended to make programs shorter. It was intendeda to correct the
> random termination statuses of countless numbers of programs in a single
> stroke.

Agreed.

> Deliberately relying on this in a new program is like relying ona a
> diaper. If you're of intermediate age, you don't do this.

No, deliberately relying on this in a new program is like relying on a
language feature that's been clearly specified for the past quarter
century.

If I relied only on language features that I *like*, I wouldn't be able
to write much code.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

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

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

csiph-web