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

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

solution allocation of memory and composite numbers

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

Contents

  solution allocation of memory and composite numbers Dexterr <dejangru@gmail.com> - 2014-12-24 05:52 -0800
    Re: solution allocation of memory and composite numbers Dexterr <dejangru@gmail.com> - 2014-12-24 05:55 -0800
      Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 06:41 -0800
        Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-24 20:16 +0000
          Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 12:39 -0800
            Re: solution allocation of memory and composite numbers Richard Heathfield <invalid@see.sig.invalid> - 2014-12-24 21:22 +0000
              Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-24 22:33 +0000
                Re: solution allocation of memory and composite numbers Richard Heathfield <invalid@see.sig.invalid> - 2014-12-25 00:54 +0000
                  Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 18:38 -0800
                  Re: solution allocation of memory and composite numbers Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-25 12:07 +0100
                  Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-26 22:05 +0000
                    Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-26 22:33 +0000
                      Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-27 22:08 +0000
                        Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-27 23:28 +0000
                        Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-29 18:34 +0000
                          Re: solution allocation of memory and composite numbers raltbos@xs4all.nl (Richard Bos) - 2014-12-30 19:23 +0000
                    Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-26 15:43 -0800
                      Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-26 15:59 -0800
                      Re: solution allocation of memory and composite numbers Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-27 14:45 +0100
                      Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-27 21:55 +0000
                        Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-27 14:07 -0800
                          Re: solution allocation of memory and composite numbers Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-27 23:44 +0100
                            Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-27 15:49 -0800
                            Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-27 21:52 -0800
                              Re: solution allocation of memory and composite numbers Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-28 15:54 +0100
                          Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-28 00:03 +0000
                    Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-26 17:13 -0800
                      Re: solution allocation of memory and composite numbers Geoff <geoff@invalid.invalid> - 2014-12-27 10:23 -0800
                        Re: solution allocation of memory and composite numbers Stephen Sprunk <stephen@sprunk.org> - 2014-12-27 13:03 -0600
                          Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-27 12:24 -0800
                        Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-27 12:23 -0800
                        Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-27 13:31 -0800
                        Re: solution allocation of memory and composite numbers Öö Tiib <ootiib@hot.ee> - 2014-12-27 18:42 -0800
                          Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-27 22:07 -0800
                        Re: solution allocation of memory and composite numbers raltbos@xs4all.nl (Richard Bos) - 2014-12-30 19:26 +0000
                          Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 20:01 +0000
                            Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 12:18 -0800
                              Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 21:15 +0000
                                Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 13:49 -0800
                                  Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 22:03 +0000
                                    Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 23:57 +0000
                                Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-30 22:35 +0000
                            Re: solution allocation of memory and composite numbers Dr Nick <nospam-4@temporary-address.org.uk> - 2014-12-31 12:24 +0000
                              Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-31 17:08 +0000
                                Re: solution allocation of memory and composite numbers Dr Nick <nospam-4@temporary-address.org.uk> - 2014-12-31 17:37 +0000
                        Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 20:09 +0000
                          Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 12:24 -0800
                            Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 21:28 +0000
                              Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 13:53 -0800
                                Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2015-01-04 02:22 +0000
                        Re: solution allocation of memory and composite numbers Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2014-12-31 13:32 +0100
                    Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-27 01:37 +0000
                    Re: solution allocation of memory and composite numbers raltbos@xs4all.nl (Richard Bos) - 2014-12-27 12:19 +0000
                      Re: solution allocation of memory and composite numbers gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-27 14:39 +0000
            Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-24 22:29 +0000
      Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-24 15:05 +0000
    Re: solution allocation of memory and composite numbers Richard Heathfield <invalid@see.sig.invalid> - 2014-12-24 16:55 +0000
      iso646.h Noob <root@127.0.0.1> - 2014-12-25 18:26 +0100
        Re: iso646.h Geoff <geoff@invalid.invalid> - 2014-12-25 18:31 -0800
          Re: iso646.h Noob <root@127.0.0.1> - 2014-12-26 18:23 +0100
        Re: iso646.h Keith Thompson <kst-u@mib.org> - 2014-12-25 21:31 -0800
          Re: iso646.h fir <profesor.fir@gmail.com> - 2014-12-26 09:42 -0800
    Re: solution allocation of memory and composite numbers Barry Schwarz <schwarzb@dqel.com> - 2014-12-24 09:06 -0800
    Re: solution allocation of memory and composite numbers Richard Heathfield <invalid@see.sig.invalid> - 2014-12-24 16:59 +0000
    Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-24 17:26 +0000
      Re: solution allocation of memory and composite numbers asetofsymbols@gmail.com - 2014-12-24 11:42 -0800

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

#55383 — solution allocation of memory and composite numbers

Hello for all gentleman.

YES, this is a homework !!!
This is a homework from this "usenet" 
and my teacher is Mr Richard Heathfield,
probably the best one in my whole life.

The task was: 
"Write a program that accepts a number in the 
range 100-200 from the user WITHOUT using scanf (hint: fgets, strtoul). 
Allocate as many ints as he asks for (hint: malloc). If the allocation 
fails, print an explanation and quit. Otherwise, fill the array with numbers 
from 0 up to (but not including - why not?) the number he typed. Replace all 
composite numbers (and 1) with 0. Then print out the non-zero values (the 
primes). Don't forget to free the memory at the end."

---------------------------- first solution ---------------------------------

/* hw_richard_v2.c - proba */

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

#define SIZE  125
#define OR    ||

void inArray(int *inNumber)
{
  int size;
  size = *inNumber;
  int array[size];
  int i;
  
  for(i = 0; i < size; i++) {
	  array[i] = i;
  }
  
  for(i = 0; i < size; i++) {
    if(array[i] % 2 == 0)
	{
	  array[i] = 0;
	}
	else {
	  array[i] = i;
	}
  }
  array[1] = 0;
  
  for(i = 0; i < size; i++)
  {
    if(array[i] != 0)
	{
	  printf("%d ", array[i]);
	}
      
  }
  
}

int main(void)
{
  unsigned long ul;
  int inputNum;
  // Allocate as many ints as he asks for (hint: malloc).
  char *buffer = malloc(sizeof(char) * SIZE); 
  
  printf("Enter some number between 100 and 200: ");
  
  if (buffer == NULL) {
    printf("Out of memory");
	return 1;
  }
  fgets(buffer, SIZE, stdin);
  
  ul = strtoul(buffer, NULL, 0);
  printf("You entered %lu", ul);
  printf("\n");
  
  if(ul < 100 OR ul > 200)
  {
    printf("You entered a wrong number!");
	return 0;
  }
  
  inputNum = ul;  
  
  inArray(&inputNum);
  
  free(buffer);
  buffer = NULL;
  return 0;
}

--------------------------------- the second solution --------------------------

/* hw_richard_v3.c - nova verzija - proba */

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

#define SIZE  125
#define OR    ||

void inArray(int *inNumber)
{
  int size;
  size = *inNumber;
  int array[size];
  int i;
  
  for(i = 0; i < size; i++) {
	  array[i] = i;
  }
  
  for(i = 0; i < size; i++) {
    if(array[i] % 2 == 0)
	{
	  array[i] = 0;
	}
	else {
	  array[i] = i;
	}
  }
  array[1] = 0;
  
  for(i = 0; i < size; i++)
  {
    if(array[i] != 0)
	{
	  printf("%d ", array[i]);
	}
      
  }
  
}

int main(void)
{
  unsigned long ul;
  int inputNum;
  // Allocate as many ints as he asks for (hint: malloc).
  char *buffer = malloc(sizeof(char) * SIZE); 
  
  if (buffer != NULL)
  {
	  printf("Enter some number between 100 and 200: ");
	  
	  fgets(buffer, SIZE, stdin);
	  
	  ul = strtoul(buffer, NULL, 0);
	  printf("You entered %lu", ul);
	  printf("\n");
	  
	  if(ul < 100 OR ul > 200)
	  {
		printf("%lu is a wrong number!", ul);
		return 0;
	  }
	  
	  inputNum = ul;  
	  
	  inArray(&inputNum);
	  
	  free(buffer);
	  buffer = NULL;
  } 
  else {
    printf("Out of memory!");
	return 1;
  }
  return 0;
}

// ------------------------- end of program --------------------------------


My question ?

How can I improve if someone input a string more then 125 chars as I defined
at the beginning ?

Here i have allocated SIZE of 125 chars:

char *buffer = malloc(sizeof(char) * SIZE);

But what is going on if someone type for instance > 125 fajkdsajfajfafdasflöfj
 .... a string with more than 125. 

OK I now for realloc but I am not smart how to implement realloc in this situation ?

Regards.

Dejan

[toc] | [next] | [standalone]

#55384

On Wednesday, December 24, 2014 2:52:32 PM UTC+1, Dexterr wrote:
> Hello for all gentleman.
> 
> YES, this is a homework !!!
> This is a homework from this "usenet" 
> and my teacher is Mr Richard Heathfield,
> probably the best one in my whole life.
> 
> The task was: 
> "Write a program that accepts a number in the 
> range 100-200 from the user WITHOUT using scanf (hint: fgets, strtoul). 
> Allocate as many ints as he asks for (hint: malloc). If the allocation 
> fails, print an explanation and quit. Otherwise, fill the array with numbers 
> from 0 up to (but not including - why not?) the number he typed. Replace all 
> composite numbers (and 1) with 0. Then print out the non-zero values (the 
> primes). Don't forget to free the memory at the end."
> 
> ---------------------------- first solution ---------------------------------
> 
> /* hw_richard_v2.c - proba */
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> #define SIZE  125
> #define OR    ||
> 
> void inArray(int *inNumber)
> {
>   int size;
>   size = *inNumber;
>   int array[size];
>   int i;
>   
>   for(i = 0; i < size; i++) {
> 	  array[i] = i;
>   }
>   
>   for(i = 0; i < size; i++) {
>     if(array[i] % 2 == 0)
> 	{
> 	  array[i] = 0;
> 	}
> 	else {
> 	  array[i] = i;
> 	}
>   }
>   array[1] = 0;
>   
>   for(i = 0; i < size; i++)
>   {
>     if(array[i] != 0)
> 	{
> 	  printf("%d ", array[i]);
> 	}
>       
>   }
>   
> }
> 
> int main(void)
> {
>   unsigned long ul;
>   int inputNum;
>   // Allocate as many ints as he asks for (hint: malloc).
>   char *buffer = malloc(sizeof(char) * SIZE); 
>   
>   printf("Enter some number between 100 and 200: ");
>   
>   if (buffer == NULL) {
>     printf("Out of memory");
> 	return 1;
>   }
>   fgets(buffer, SIZE, stdin);
>   
>   ul = strtoul(buffer, NULL, 0);
>   printf("You entered %lu", ul);
>   printf("\n");
>   
>   if(ul < 100 OR ul > 200)
>   {
>     printf("You entered a wrong number!");
> 	return 0;
>   }
>   
>   inputNum = ul;  
>   
>   inArray(&inputNum);
>   
>   free(buffer);
>   buffer = NULL;
>   return 0;
> }
> 
> --------------------------------- the second solution --------------------------
> 
> /* hw_richard_v3.c - nova verzija - proba */
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> #define SIZE  125
> #define OR    ||
> 
> void inArray(int *inNumber)
> {
>   int size;
>   size = *inNumber;
>   int array[size];
>   int i;
>   
>   for(i = 0; i < size; i++) {
> 	  array[i] = i;
>   }
>   
>   for(i = 0; i < size; i++) {
>     if(array[i] % 2 == 0)
> 	{
> 	  array[i] = 0;
> 	}
> 	else {
> 	  array[i] = i;
> 	}
>   }
>   array[1] = 0;
>   
>   for(i = 0; i < size; i++)
>   {
>     if(array[i] != 0)
> 	{
> 	  printf("%d ", array[i]);
> 	}
>       
>   }
>   
> }
> 
> int main(void)
> {
>   unsigned long ul;
>   int inputNum;
>   // Allocate as many ints as he asks for (hint: malloc).
>   char *buffer = malloc(sizeof(char) * SIZE); 
>   
>   if (buffer != NULL)
>   {
> 	  printf("Enter some number between 100 and 200: ");
> 	  
> 	  fgets(buffer, SIZE, stdin);
> 	  
> 	  ul = strtoul(buffer, NULL, 0);
> 	  printf("You entered %lu", ul);
> 	  printf("\n");
> 	  
> 	  if(ul < 100 OR ul > 200)
> 	  {
> 		printf("%lu is a wrong number!", ul);
> 		return 0;
> 	  }
> 	  
> 	  inputNum = ul;  
> 	  
> 	  inArray(&inputNum);
> 	  
> 	  free(buffer);
> 	  buffer = NULL;
>   } 
>   else {
>     printf("Out of memory!");
> 	return 1;
>   }
>   return 0;
> }
> 
> // ------------------------- end of program --------------------------------
> 
> 
> My question ?
> 
> How can I improve if someone input a string more then 125 chars as I defined
> at the beginning ?
> 
> Here i have allocated SIZE of 125 chars:
> 
> char *buffer = malloc(sizeof(char) * SIZE);
> 
> But what is going on if someone type for instance > 125 fajkdsajfajfafdasflöfj
>  .... a string with more than 125. 
> 
> OK I now for realloc but I am not smart how to implement realloc in this situation ?
> 
> Regards.
> 
> Dejan

I have to say thanks for this task and all instructions I got from Mr Richard Heathfield.

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

#55385

On Wednesday, December 24, 2014 1:55:29 PM UTC, Dexterr wrote:
> 
> I have to say thanks for this task and all instructions I got 
> from Mr Richard Heathfield.
>
It's quite hard to write robust C input functions.

First take in a line using fgets().
If fgets() returns NULL, something has gone wrong, terminate.
Now check that the last character is a newline. If it is not, the line
was bigger than your buffer. That usually means either a corrupt input
or someone is deliberately trying to crash your program.
If the line was too big, take action. Normally you want to read input
until the newline to get rid of the half-read line still in the buffer,
then treat was an error.

Now we've got a line.

  
Now call strtoul on the line. Don't use NULL for the end pointer, 
set it to a char * called end.
If end equals the input pointer, strtoul has failed, the input wasn't
a number.
If end doesn't equal the input pointer, strtoul has succeeded, but
there might be garbage (or e12 or some sort of notation we can't
handle) following the digits. Or there might be a ridiculously
large number in there, that overflows the size of a long.
So increment end until you hit the end of string Nul (not NULL),
checking for non-whitespace. 
If you detect any non-whitespace, there's garbage after the digits,
treat as an error.

Now we've got a line which contains a valid unsigned integer.
Convert it, and range-check it.

It's quite involved, unfortunately there's just no good way to
handle erroneous input, whatever you do it's difficult to program
robustly and give useful messages to the user.

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

#55399

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> It's quite involved, unfortunately there's just no good way to
> handle erroneous input, whatever you do it's difficult to program
> robustly and give useful messages to the user.

Yes, it is.  So why not write

  if (scanf("%d", &number) == 1 && /* other checks... */) {
     /* use the input */
  }

?  For this sort of program, beginners often get better code using
scanf.  There's plenty of time to learn abut parsing mini input
languages later.  The whole "you must use fgets & strtol" (both hard to
use correctly) just puts a huge barrier up to getting started.

-- 
Ben.

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

#55405

On Wednesday, December 24, 2014 8:16:59 PM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> <snip>
> > It's quite involved, unfortunately there's just no good way to
> > handle erroneous input, whatever you do it's difficult to program
> > robustly and give useful messages to the user.
> 
> Yes, it is.  So why not write
> 
>   if (scanf("%d", &number) == 1 && /* other checks... */) {
>      /* use the input */
>   }
> 
> ?  For this sort of program, beginners often get better code using
> scanf.  There's plenty of time to learn abut parsing mini input
> languages later.  The whole "you must use fgets & strtol" (both hard to
> use correctly) just puts a huge barrier up to getting started.
> 
Richard Heathfield banned scanf().

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

#55411

Malcolm McLean wrote:

> On Wednesday, December 24, 2014 8:16:59 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> <snip>
>> > It's quite involved, unfortunately there's just no good way to
>> > handle erroneous input, whatever you do it's difficult to program
>> > robustly and give useful messages to the user.
>> 
>> Yes, it is.  So why not write
>> 
>>   if (scanf("%d", &number) == 1 && /* other checks... */) {
>>      /* use the input */
>>   }
>> 
>> ?  For this sort of program, beginners often get better code using
>> scanf.  There's plenty of time to learn abut parsing mini input
>> languages later.  The whole "you must use fgets & strtol" (both hard to
>> use correctly) just puts a huge barrier up to getting started.
>> 
> Richard Heathfield banned scanf().

And with good reason. Ben underestimates the difficulties that beginners 
have with scanf. It is an astoundingly difficult function to use safely and 
correctly. Dan Pop used to show off an extraordinarily complicated way in 
which it could be used to garner a string safely, but I would not like to 
have to be the one to explain that technique.

The fgets function is simple to use correctly and safely. So is the strto* 
numerical conversion function family.

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

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

#55416

Richard Heathfield <invalid@see.sig.invalid> writes:

> Malcolm McLean wrote:
>
>> On Wednesday, December 24, 2014 8:16:59 PM UTC, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> <snip>
>>> > It's quite involved, unfortunately there's just no good way to
>>> > handle erroneous input, whatever you do it's difficult to program
>>> > robustly and give useful messages to the user.
>>> 
>>> Yes, it is.  So why not write
>>> 
>>>   if (scanf("%d", &number) == 1 && /* other checks... */) {
>>>      /* use the input */
>>>   }
>>> 
>>> ?  For this sort of program, beginners often get better code using
>>> scanf.  There's plenty of time to learn abut parsing mini input
>>> languages later.  The whole "you must use fgets & strtol" (both hard to
>>> use correctly) just puts a huge barrier up to getting started.
>>> 
>> Richard Heathfield banned scanf().
>
> And with good reason. Ben underestimates the difficulties that beginners 
> have with scanf.

No I don't.  I have much experience of it.  Might you be underestimating
the trouble beginners have with fgets and strtol (et al)?

> It is an astoundingly difficult function to use safely and 
> correctly.

  if (scanf("%d", &number) == 1)

is safe and correct, provided you get to choose what "correct" means,
and, as an instructor, you do!  If you design the specification to suit
simple use of scanf, you can defer a whole lot of trouble until later.

<snip>
-- 
Ben.

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

#55421

Ben Bacarisse wrote:

> Richard Heathfield <invalid@see.sig.invalid> writes:
> 
>> Malcolm McLean wrote:
>>
>>> On Wednesday, December 24, 2014 8:16:59 PM UTC, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>> <snip>
>>>> > It's quite involved, unfortunately there's just no good way to
>>>> > handle erroneous input, whatever you do it's difficult to program
>>>> > robustly and give useful messages to the user.
>>>> 
>>>> Yes, it is.  So why not write
>>>> 
>>>>   if (scanf("%d", &number) == 1 && /* other checks... */) {
>>>>      /* use the input */
>>>>   }
>>>> 
>>>> ?  For this sort of program, beginners often get better code using
>>>> scanf.  There's plenty of time to learn abut parsing mini input
>>>> languages later.  The whole "you must use fgets & strtol" (both hard to
>>>> use correctly) just puts a huge barrier up to getting started.
>>>> 
>>> Richard Heathfield banned scanf().

(I noticed that you unbanned it again. That's the ticket! Cultural diversity 
is *so* important. But I'm still maintaining the ban. Now, if *you* would be 
so kind as to make it mandatory, we present our newbies with a philosophical 
conundrum (should I or shouldn't I?), which will of course be extremely good 
for them.

>>
>> And with good reason. Ben underestimates the difficulties that beginners
>> have with scanf.
> 
> No I don't.  I have much experience of it.

If you mean you have much experience of the function, I'm sorry to hear 
that. If you mean you have much experience of the difficulty that beginners 
have with it, then I'm... surprised that you advocate it.

> Might you be underestimating
> the trouble beginners have with fgets and strtol (et al)?

Oh, of course that's possible. But they aren't as hard to teach, or to 
learn, as scanf.

> 
>> It is an astoundingly difficult function to use safely and
>> correctly.
> 
>   if (scanf("%d", &number) == 1)
> 
> is safe and correct, provided you get to choose what "correct" means,

Not only do I get to choose what "correct" means, but I get to choose in 
which order I teach things, and input definitely comes before &.

> and, as an instructor, you do!  If you design the specification to suit
> simple use of scanf, you can defer a whole lot of trouble until later.

And if I design the specification to suit simple use of fgets and strtoul, I 
can defer a different whole lot of trouble until later. :-)

Oh, one more thing...
    Compliments of the season.

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

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

#55423

On Thursday, December 25, 2014 2:07:55 AM UTC, Stefan Ram wrote:
> 
>   In my beginner's C course there is very little time:
>   only 18 hours, including time for exercises, which are
>   all done in the classroom (there is no homework).
> 
>   So, I usually do not teach neither pointers nor scanf
>   in the beginner's course.
> 
>   However, the students of my course are entitled to wish
>   for topics for the last hours of the course. In the course
>   that just ended two weeks ago, a student wished for the topic
>   of pointers. So I taught pointers, and while I was already
>   at it, I also explained scanf /after/ having explained »&«.
> 
>   Otherwise, I would explain pointers in the advanced course,
>   but currently there is no advanced course established for C.
>
That's kind of pointless.

C is the language that uses pointers to pass memory buffers
to subroutines and string them together into arbitrarily
complex structures. That's the heart and soul of C, the whole
reason for using it instead of Fortran or Basic.

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

#55430

Il 25/12/2014 03:07, Stefan Ram ha scritto:
..
>
>    In my beginner's C course there is very little time:
>    only 18 hours, including time for exercises, which are
>    all done in the classroom (there is no homework).
>
>    So, I usually do not teach neither pointers nor scanf
>    in the beginner's course.
>
>    However, the students of my course are entitled to wish
>    for topics for the last hours of the course. In the course
>    that just ended two weeks ago, a student wished for the topic
>    of pointers. So I taught pointers, and while I was already
>    at it, I also explained scanf /after/ having explained »&«.
>
>    Otherwise, I would explain pointers in the advanced course,
>    but currently there is no advanced course established for C.
>

IMHO, if you only have 18 hours for a course on C, letting
students choose what they need to learn in the "last hours"
is a bit of an hazard. Pointers in C need to be considered as
what they are, a fundamental characteristic of the language.
I'd rather introduce pointers just after the arithmetic types,
perhaps paying more attention to the initialization syntax,
as well as the assignment. Then what dereferencing a pointer
means, in what arrays and pointers are different and how and
when arrays decay into pointers. These would be my last hours
in a course for beginners. I'd rather defer, until a more
advanced course, topics like casts, dynamic allocation,
multidimensional arrays, function pointers, along with the
introduction to the rest of the standard library. I think that
many of the misconceptions surrounding pointers are also due
to how they are considered an "extra feature", not objects of
a type just like the others. I believe it's capital how students
perceive the importance of what they need to learn first, and
pointers in C belong to the fundamentals of the language.
Just my opinion.

-- 
Vincenzo Mercuri

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

#55465

Richard Heathfield <invalid@see.sig.invalid> writes:

> Ben Bacarisse wrote:
>
>> Richard Heathfield <invalid@see.sig.invalid> writes:
>> 
>>> Malcolm McLean wrote:
>>>
>>>> On Wednesday, December 24, 2014 8:16:59 PM UTC, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>> <snip>
>>>>> > It's quite involved, unfortunately there's just no good way to
>>>>> > handle erroneous input, whatever you do it's difficult to program
>>>>> > robustly and give useful messages to the user.
>>>>> 
>>>>> Yes, it is.  So why not write
>>>>> 
>>>>>   if (scanf("%d", &number) == 1 && /* other checks... */) {
>>>>>      /* use the input */
>>>>>   }
>>>>> 
>>>>> ?  For this sort of program, beginners often get better code using
>>>>> scanf.  There's plenty of time to learn abut parsing mini input
>>>>> languages later.  The whole "you must use fgets & strtol" (both hard to
>>>>> use correctly) just puts a huge barrier up to getting started.
>>>>> 
>>>> Richard Heathfield banned scanf().
<snip>
>>>
>>> And with good reason. Ben underestimates the difficulties that beginners
>>> have with scanf.
>> 
>> No I don't.  I have much experience of it.
>
> If you mean you have much experience of the function, I'm sorry to hear 
> that. If you mean you have much experience of the difficulty that beginners 
> have with it, then I'm... surprised that you advocate it.

The experience I have of the trouble beginners have with scanf tells me
that it's not as bad as you seem to suggest (what else could I have
meant?).  It doesn't seem to me to "astoundingly difficult" to use
safely and correctly.

>> Might you be underestimating
>> the trouble beginners have with fgets and strtol (et al)?
>
> Oh, of course that's possible. But they aren't as hard to teach, or to 
> learn, as scanf.

We will just have to agree to differ there.  For reading a few numbers
in simple early programs I see no reason to ban scanf.

>>> It is an astoundingly difficult function to use safely and
>>> correctly.
>> 
>>   if (scanf("%d", &number) == 1)

Do you think this is "astoundingly difficult"?

>> is safe and correct, provided you get to choose what "correct" means,
>
> Not only do I get to choose what "correct" means, but I get to choose in 
> which order I teach things, and input definitely comes before &.

Can you show me what you advocate to replace the line above so I can get
an idea of what you do teach before input.  For example, do you gloss
over the array-to-pointer conversion in fgets?  Do you avoid using the
second parameter of strtol?  How much effort do you put in testing for
proper input?

I find a quick, "this lets scanf alter number -- you'll see what it
means in detail later" is all that's needed to explain the &.

>> and, as an instructor, you do!  If you design the specification to suit
>> simple use of scanf, you can defer a whole lot of trouble until later.
>
> And if I design the specification to suit simple use of fgets and strtoul, I 
> can defer a different whole lot of trouble until later. :-)

I'd like to see an example -- numerical input designed with fgets and
strtoul in mind, just so I can see what I might have been overlooking.
It doesn't seem simpler to me...

<snip>
-- 
Ben.

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

#55466

On 26/12/2014 22:05, Ben Bacarisse wrote:

>>>    if (scanf("%d", &number) == 1)
>
> Do you think this is "astoundingly difficult"?

It doesn't do the same thing as fgets() followed by some string to 
integer conversion.

For a start, it ignores white space including newlines, looking for 
input. Someone used to getting feedback after hitting Enter may be 
confused as to why nothing happens. They hit Enter a few more times, and 
still nothing happens.

(Yes they have been told to type a number, but if they want to abort 
because they got there by mistake or for any reason, there's no obvious 
way to do so. Except perhaps Ctrl Z. It's also easy to get of step if so 
many numbers per line are needed, and one is missed out, or a separator 
is omitted.)

And, it doesn't seem to report out-of-range input, not as used above anyway.

-- 
Bartc

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

#55518

BartC <bc@freeuk.com> writes:

> On 26/12/2014 22:05, Ben Bacarisse wrote:
>
>>>>    if (scanf("%d", &number) == 1)
>>
>> Do you think this is "astoundingly difficult"?
>
> It doesn't do the same thing as fgets() followed by some string to
> integer conversion.
>
> For a start, it ignores white space including newlines, looking for
> input. Someone used to getting feedback after hitting Enter may be
> confused as to why nothing happens. They hit Enter a few more times,
> and still nothing happens.
>
> (Yes they have been told to type a number, but if they want to abort
> because they got there by mistake or for any reason, there's no
> obvious way to do so. Except perhaps Ctrl Z. It's also easy to get of
> step if so many numbers per line are needed, and one is missed out, or
> a separator is omitted.)
>
> And, it doesn't seem to report out-of-range input, not as used above
> anyway.

All true (and hardly news!) but what would you teach beginners to get
them started writing C programs?  I really want to know what the "ban
scanf" sect would rather do -- as actual code.

-- 
Ben.

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

#55522

On 27/12/2014 22:08, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> It doesn't do the same thing as fgets() followed by some string to
>> integer conversion.

>> And, it doesn't seem to report out-of-range input, not as used above
>> anyway.
>
> All true (and hardly news!)

It's sort of news to me because I rarely use those functions (they're 
used once in a library somewhere then forgotten about).

> but what would you teach beginners to get
> them started writing C programs?  I really want to know what the "ban
> scanf" sect would rather do -- as actual code.

I would have a problem teaching raw, unadorned C.

The first languages I learned I believe had this console input stuff all 
built-in to the language so that it wasn't an obstacle to doing anything 
more interesting.

I think I would have a small library of a handful of functions and make 
use of that until the topic turned to doing user input directly using 
the standard library.

-- 
Bartc

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

#55566

On 29/12/2014 17:12, Stefan Ram wrote:

>    Under Microsoft® Windows, the console has another drawback.
>    I am living in a country where they write a language called
>    »German« that uses non-ASCII characters such as »ß«. It is
>    usually difficult to write such characters to the Microsoft®
>    Windows console, while it is no problem to write them to a
>    GUI, since the GUI uses the same encoding as the source-code
>    editor, while the Microsoft® Windows console does not.

In Windows, ß is written to the console using character code 223. It can 
be entered from a console using Alt 0223 on the numeric pad (not Alt 223).

A GUI app also uses Alt 0223 to enter ß (on a keyboard that doesn't have 
a key for it).

So I'm not sure what the problem is. What did they do in Germany in the 
decades before GUI apps became widespread?

-- 
Bartc

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

#55594

BartC <bc@freeuk.com> wrote:

> So I'm not sure what the problem is. What did they do in Germany in the 
> decades before GUI apps became widespread?

Pfft, children these days... molly-coddled cokeneys, one and all. Tell
them how hard we had it back and and they won't believe you.

<http://en.wikipedia.org/wiki/Code_page_437>
<http://en.wikipedia.org/wiki/Code_page>
<http://en.wikipedia.org/wiki/German_keyboard_layout>

And we in the Netherlands had it _both_ ways -
<http://en.wikipedia.org/wiki/Dutch_keyboard_layout#Dutch_.28Netherlands.29>
wasn't even remotely useful for Dutch at all.

Richard

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

#55467

On Friday, December 26, 2014 10:05:29 PM UTC, Ben Bacarisse wrote:
> Richard Heathfield <invalid@see.sig.invalid> writes:
> 
> > Ben Bacarisse wrote:
> 
> >>   if (scanf("%d", &number) == 1)
> 
> Do you think this is "astoundingly difficult"?
>
Tempting, but it's undefined behaviour if fed with a huge integer like
"10000000000000000000000000000000000000", in C89 at least. No sane
implementation would crash out, but it's not clear how it should
behave.
The worst feature is that

scanf("%d, %d\n", &a, &b)

when fed with

100,
200

will still convert 2 fields.

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

#55468

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, December 26, 2014 10:05:29 PM UTC, Ben Bacarisse wrote:
>> Richard Heathfield <invalid@see.sig.invalid> writes:
>> 
>> > Ben Bacarisse wrote:
>> 
>> >>   if (scanf("%d", &number) == 1)
>> 
>> Do you think this is "astoundingly difficult"?
>>
> Tempting, but it's undefined behaviour if fed with a huge integer like
> "10000000000000000000000000000000000000", in C89 at least. No sane
> implementation would crash out, but it's not clear how it should
> behave.

It's still undefined in C99 and C11.

> The worst feature is that
>
> scanf("%d, %d\n", &a, &b)
>
> when fed with
>
> 100,
> 200
>
> will still convert 2 fields.

Because it treats newlines as whitespace.  Yes, that can be
annoying.  I suspect it was originally designed for batch rather
than interactive input.  If you're reading a sequence of numbers
from a file (or from a card reader), ignoring newlines might make
a bit more sense.

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

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

#55485

Il 27/12/2014 00:43, Malcolm McLean ha scritto:
> On Friday, December 26, 2014 10:05:29 PM UTC, Ben Bacarisse wrote:
>> Richard Heathfield <invalid@see.sig.invalid> writes:
>>
>>> Ben Bacarisse wrote:
>>
>>>>    if (scanf("%d", &number) == 1)
>>
>> Do you think this is "astoundingly difficult"?
>>
> Tempting, but it's undefined behaviour if fed with a huge integer like
> "10000000000000000000000000000000000000", in C89 at least. No sane
> implementation would crash out, but it's not clear how it should
> behave.
..

True. However, Ben has a point. We all know that a "serious"
program will never rely on *scanf() to read input values, but
at the same time, it's the simplest way to read from stdin
for teaching purposes. If you are concerned about handling
overflows in input, you are not going to use *scanf() in the
first place. Arithmetic overflow is the "real" problem with
*scanf(). Buffer overflow itself can be prevented by explicitly
setting the /field width/: "%64s" and alike..
Richard also has a point when it comes to teach "best practices",
which inevitably involve more complexity in this case, which is
ok at a bit more advanced level.

-- 
Vincenzo Mercuri

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

#55515

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Friday, December 26, 2014 10:05:29 PM UTC, Ben Bacarisse wrote:
>> Richard Heathfield <invalid@see.sig.invalid> writes:
>> 
>> > Ben Bacarisse wrote:
>> 
>> >>   if (scanf("%d", &number) == 1)
>> 
>> Do you think this is "astoundingly difficult"?
>>
> Tempting, but it's undefined behaviour if fed with a huge integer like
> "10000000000000000000000000000000000000", in C89 at least. No sane
> implementation would crash out, but it's not clear how it should
> behave.
> The worst feature is that
>
> scanf("%d, %d\n", &a, &b)
>
> when fed with
>
> 100,
> 200
>
> will still convert 2 fields.

Why is that not the best feature of scanf?

To be less cryptic, I think you missed the point.  In this context the
instructor gets to choose the input format and what should and should
not be handled and how.  The instructor can set things up so that
students make headway with a whole range of things (functions,
variables, arithmetic, control flow and so on) without input being a
huge barrier.

What would you suggest in place of

  if (scanf("%d", &number) == 1)

in an introductory C course?

-- 
Ben.

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

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

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

csiph-web