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

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

Issues with setting variables to true or false: how does the compiler understands it

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

Contents

  Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 02:17 -0700
    Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 03:29 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 03:38 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 04:30 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-24 12:04 +0000
    Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 04:59 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 14:28 +0100
        Re: Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 07:26 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 17:06 +0100
    Re: Issues with setting variables to true or false: how does the compiler understands it James Kuyper <jameskuyper@verizon.net> - 2015-10-24 11:56 -0400
      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:02 -0700
        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 15:45 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 16:28 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 16:44 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:34 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:30 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 20:33 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 11:16 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-28 15:12 -0400
                Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-29 12:18 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it raltbos@xs4all.nl (Richard Bos) - 2015-10-29 21:51 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:38 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 05:34 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-28 14:08 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 06:14 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:50 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 15:08 -0700
                  Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 22:47 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 18:35 -0500
                      Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:12 -0700
                      Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-29 01:35 +0000
                        Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 21:12 -0500
                          Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 19:52 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:01 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 03:47 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-24 09:54 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:13 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:50 +0100
    Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 04:04 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-25 08:32 -0700
        Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:19 +0000
        Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 11:30 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:56 +0000
            Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 20:59 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-25 21:49 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 08:10 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-26 16:05 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 00:34 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:04 -0700
                        Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 21:24 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 18:16 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:33 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:08 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 11:22 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 11:35 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:00 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 17:59 +0000
            Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 07:55 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:06 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-26 10:56 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 20:14 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 17:09 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-26 23:39 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 12:31 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 12:45 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:24 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:41 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 19:43 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 19:47 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 13:20 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:28 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:54 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 07:51 -0700
                      Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 16:46 +0000
                        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 10:52 -0700
                          Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 18:51 +0000
                            Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 12:17 -0700
                              Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 19:34 +0000
                                Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:10 -0700
                                  Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 13:41 -0700
                                  Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 23:11 +0000
                                    Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 19:02 -0700
                                      Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-28 07:09 +0000
                                    Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 11:27 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 12:27 -0700
                        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:18 -0700

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

#73676 — Issues with setting variables to true or false: how does the compiler understands it

Hello!

I am not rushing anywhere ahead, and I am still
working on the previous program, but meanwhile
I have stumbled upon the program that has if statements
resembling the ones I have asked about.

The program is from the textbook Head First, and, please,
note that it doesn't print out the output neatly, as 
authors mention it (later they show how to solve this,
but that is not appropriate for me now - too early for 
this). 

Quote: This program can read comma-separated data from the command line and then display it in JSON format.

I understand everything in the program, except for
the usage of 'int started' within 'if else' statement.

 Here is the comment at the 'if (started)' line:

/**"You'll display a comma only if you've
already displayed a previous line.**/

I assume the compiler knows that the previous line has been
displayed by receiving the '\n' input from the user, correct?
Then 'started' should be false, and the program displays a comma.

Is the following process correct:

- the user types in the first line of data;
- the user hits ENTER;
- upon receiving '\n', the program should print 
out the first line, and then
- display a comma.

How does the program know how to do that, if 
'started' has been initially set to 0, and not yet changed
when the while loop starts for the fist time? Why the comma
is not displayed first, if 'if(started)' comes first?

Does 'if(started)' here mean 'if started is false', or
does 'if (started)' mean the same as if statement with a NULL pointer,
where 'if (pointer != NULL)' is the same as 'if (pointer)?

My confusion is about the 'started' variable.

#include <stdio.h>
 int main()
{
    float latitude;
    float longitude;
    char info[80];
    int started = 0; /**"We need to begin with "started" set       
                     to 0, which means false."**/

    puts("data=[");

    while (scanf("%f,%f,%79[^\n]", , , ) == 3) 
   {
          if (started)
              printf(",\n"); /**"You'll display a comma only if you've
                             already displayed a previous line.**/
          else
              started = 1; /** "Once the loop has started, you can
                            set "started" to 1, which is true.**/

          printf("{latitude: %f, longitude: %f, info: '%s'}", , , );
   }

   puts("\n]");

   return 0;
}

Thank you!

[toc] | [next] | [standalone]

#73680

Alla wrote:
>scanf("%f,%f,%79[^\n]", , , 

You forgot something

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

#73681

On Saturday, October 24, 2015 at 2:30:23 PM UTC+4, asetof...@gmail.com wrote:
> Alla wrote:
> >scanf("%f,%f,%79[^\n]", , , 
> 
> You forgot something

Sorry! Indeed! )

#include <stdio.h>
 int main()
{
    float latitude;
    float longitude;
    char info[80];
    int started = 0; /**"We need to begin with "started" set      
                     to 0, which means false."**/

    puts("data=[");

    while (scanf("%f,%f,%79[^\n]", &latitude , &longitude , info ) == 3)
   {
          if (started)
              printf(",\n"); /**"You'll display a comma only if you've
                             already displayed a previous line.**/
          else
              started = 1; /** "Once the loop has started, you can
                            set "started" to 1, which is true.**/

          printf("{latitude: %f, longitude: %f, info: '%s'}", latitude, longitude, info );
   }

   puts("\n]");

   return 0;
} 

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

#73683

On Saturday, October 24, 2015 at 10:17:57 AM UTC+1, Alla _ wrote:
> 
> I understand everything in the program, except for
> the usage of 'int started' within 'if else' statement.
> 
>  Here is the comment at the 'if (started)' line:
> 
> /**"You'll display a comma only if you've
> already displayed a previous line.**/
> 
> I assume the compiler knows that the previous line has been
> displayed by receiving the '\n' input from the user, correct?
>
You tell the compiler by setting the started flag, after you output
a line.

JSON has a nuisance rule that, as in English, a list may not
be terminated by a comma. Commas only appear between separate
items. This makes it a little bit awkward to generate JSON
from automatic programs. C doesn't make that mistake, a trailing
comma is allowed in data lists, for that reason.

The program is then written in a slightly confusing way. The
natural logic is "output the item, then if it is not the last,
output  a comma". Instead they've said, "unless the item is the 
first, output a trailing comma to finish the previous item, then
output the item". Both work, but the second is a bit back to
front.

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

#73685

In article <00927f5d-0dec-4fc5-974f-8691745ae0d2@googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
...
>JSON has a nuisance rule that, as in English, a list may not
>be terminated by a comma. Commas only appear between separate
>items. This makes it a little bit awkward to generate JSON
>from automatic programs. C doesn't make that mistake, a trailing
>comma is allowed in data lists, for that reason.

Agreed that it is better to allow commas at the end, but it looks funny.
I think JSON was designed to "look nice" and allowing commas at the end
would run afoul of that goal.

>The program is then written in a slightly confusing way. The
>natural logic is "output the item, then if it is not the last,
>output  a comma". Instead they've said, "unless the item is the 
>first, output a trailing comma to finish the previous item, then
>output the item". Both work, but the second is a bit back to
>front.

The problem here is that it is often hard, in a(ny) programming language,
to know when something is the last.  I.e., you only know that the thing you
were just working on was the last one, when you have (unsuccessfully) read
the next one.  So, it is usually easier to do it the second way, even if it
does feel "backwards".

You run into this problem frequently when doing (OT) AWK programming.
A common idiom there is:

:loop
IF notfirstflag is set, output a terminator
output the thing (without a terminator)
set notfirstflag
goto loop

-- 
"Although written many years ago, Lady Chatterley's Lover has just
been reissued by the Grove Press, and this fictional account of the
day-to-day life of an English gamekeeper is still of considerable
interest to outdoor minded readers, as it contains many passages on
pheasant raising, the apprehending of poachers, ways to control vermin,
and other chores and duties of the professional gamekeeper.

"Unfortunately, one is obliged to wade through many pages of extraneous
material in order to discover and savor these sidelights on the
management of a Midlands shooting estate, and in this reviewer's opinion
this book cannot take the place of J.R. Miller's Practical Gamekeeping"
(Ed Zern, Field and Stream, November 1959, p. 142).

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

#73684

In an input I prefer single variable
get as in this code found in the net:
// usage double result=GetDouble("insert a: ");
// ritorna DBL_MIN per errore 
// ritorna il double da stdin 
// 
double __export  GetDouble(char*   testo) 
{int               i,c; 
 double              v; 
 char  arr[1028], *p=0; 

 printf("%s", testo); fflush(stdout); 
 for(i=0; i<1024; ++i) 
    {c=getchar(); 
     if(c==EOF||c=='\n') 
          break; 
     arr[i]=(char)c; 
    } 
 arr[i]=0; 
 if(i==1024)   // elimina la linea fino a '\n' 
    {while((c=getchar())!=EOF) 
         if(c=='\n')  break; 
     return  DBL_MIN; 
    } 
 v=strtod(arr, &p); 
 if(v==HUGE_VAL||p==arr) 
     return  DBL_MIN; 
 return   v; 
}

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

#73686

asetofsymbols@gmail.com writes:

> In an input I prefer single variable
> get as in this code found in the net:

> // usage double result=GetDouble("insert a: ");
> // ritorna DBL_MIN per errore 
> // ritorna il double da stdin 
> // 
> double __export  GetDouble(char*   testo)
> {int               i,c; 
>  double              v; 
>  char  arr[1028], *p=0; 
>
>  printf("%s", testo); fflush(stdout);

I'd write

  if (testo) printf("%s", testo);

so that the prompt can be avoided when doing input from non-interactive
sources.

>  for(i=0; i<1024; ++i) 
>     {c=getchar(); 
>      if(c==EOF||c=='\n') 
>           break; 
>      arr[i]=(char)c; 
>     } 
>  arr[i]=0; 
>  if(i==1024)   // elimina la linea fino a '\n'
>     {while((c=getchar())!=EOF) 
>          if(c=='\n')  break; 
>      return  DBL_MIN; 
>     }

These loops are overly complex because ther use the wrong conditions.
The point is to read data up to (and including) a newline or to stop
when the input is exhausted.  Always.  The first 1024 (or so) happen to
get put into a buffer, but counting that is secondary to the main loop
condition:

  int c, i = 0;
  char line[1024];
  while ((c = getchar()) != EOF && c != '\n')
        if (i < sizeof line - 1)
           line[i++] = c;
  line[i] = 0;

>  v=strtod(arr, &p); 
>  if(v==HUGE_VAL||p==arr) 
>      return  DBL_MIN; 
>  return   v; 
> }

-- 
Ben.

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

#73688

#I write now:
Ben wrote:
>I wrote:
>  for(i=0; i<1024; ++i) 
>     {c=getchar(); 
>      if(c==EOF||c=='\n') 
>           break; 
>      arr[i]=(char)c; 
>     } 
>  arr[i]=0; 
>  if(i==1024)   // elimina la linea fino a '\n' 
>     {while((c=getchar())!=EOF) 
>          if(c=='\n')  break; 
>      return  DBL_MIN; 
>     } 


These loops are overly complex because ther use the wrong conditions. 

The point is to read data up to (and including) a newline or to stop 
when the input is exhausted.

#here we are not 100% agree
#I think in case of
#line too much long (>1024 characters)
#the action is get all input
#from stdin until '\n' or EOF
#and return error whatever 
#there is in the string.
#note:
#in every case the line is get
#from stdin .
#
#<1021 ' ' chars> 12345.67
#has to be seen as one error
#so it is better return error
# in case too much long line.
# [or one has to see that
#  arr[1023] is not
#  in the first number in the 
#  input, in that case return 
#  error, else pass the arr
#  to strtod()

  Always.  The first 1024 (or so) happen to 
get put into a buffer, but counting that is secondary to the main loop 
condition: 

  int c, i = 0; 
  char line[1024]; 
  while ((c = getchar()) != EOF && c != '\n') 
        if (i < sizeof line - 1) 
           line[i++] = c; 
  line[i] = 0; 


>  v=strtod(arr, &p); 
>  if(v==HUGE_VAL||p==arr) 
>      return  DBL_MIN; 
>  return   v; 
> } 


-- 
Ben.
______________________
##

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

#73700

I'm not sure anyone will be able to fillow the quoting.  Can't you do it
the way everyone does does it?

>> asetofsymbols@gmail.com wrote:
>>>  for(i=0; i<1024; ++i) 
>>>     {c=getchar(); 
>>>      if(c==EOF||c=='\n') 
>>>           break; 
>>>      arr[i]=(char)c; 
>>>     } 
>>>  arr[i]=0; 
>>>  if(i==1024)   // elimina la linea fino a '\n' 
>>>     {while((c=getchar())!=EOF) 
>>>          if(c=='\n')  break; 
>>>      return  DBL_MIN; 
>>>     } 
>
>
> Ben wrote:
>> These loops are overly complex because ther use the wrong conditions. 
>>
>> The point is to read data up to (and including) a newline or to stop 
>> when the input is exhausted.

asetofsymbols@gmail.com writes:
> here we are not 100% agree
> I think in case of
> line too much long (>1024 characters)
> the action is get all input
> from stdin until '\n' or EOF
> and return error whatever 
> there is in the string.

Yes, that the right thing to do, but it's not related to the point I was
making.  The code snippet I wrote had no return values at all -- you can
return what you like when the line is over-long.

-- 
Ben.

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

#73698

On 10/24/2015 05:17 AM, Alla _ wrote:
...
> I understand everything in the program, except for
> the usage of 'int started' within 'if else' statement.
> 
>  Here is the comment at the 'if (started)' line:
> 
> /**"You'll display a comma only if you've
> already displayed a previous line.**/
> 
> I assume the compiler knows that the previous line has been
> displayed by receiving the '\n' input from the user, correct?
> Then 'started' should be false, and the program displays a comma.
> 
> Is the following process correct:
> 
> - the user types in the first line of data;
> - the user hits ENTER;
> - upon receiving '\n', the program should print 
> out the first line, and then
> - display a comma.
> 
> How does the program know how to do that, if 
> 'started' has been initially set to 0, and not yet changed
> when the while loop starts for the fist time? Why the comma
> is not displayed first, if 'if(started)' comes first?
> 
> Does 'if(started)' here mean 'if started is false', or
> does 'if (started)' mean the same as if statement with a NULL pointer,
> where 'if (pointer != NULL)' is the same as 'if (pointer)?

A simple if-else statement has the form:

	if (condition) statement1 else statement2

statement1 and statement2 are allowed to be compound statements - in
other words, a '{' followed by a series of declarations and statements,
followed by a '}'. This leads some people to think that '{' and '}' are
part of the if-statement syntax, but they are not. You can put a
compound statement anywhere an ordinary statement is allowed, but it  is
only necessary if you want to put multiple statements in a place where
only one is allowed, a situation that normally only comes up when using
constructs like if(), while(), for(), do while(), and switch().

The way such an if-else statement works is as follows: the condition of
the if() statement is evaluated, and compared with 0. If it does not
compare equal to 0, statement1 is executed. If it does compare equal to
0, then statement2 is executed.

Note: when the condition has a pointer type, comparing whether it's
equal to 0 results in the 0 being treated as a null pointer constant
(NPC). When a pointer is compared with an NPC, the NPC gets converted
into a pointer of the same type as the other operand (6.5.9p5), and the
result of that conversion is a null pointer (6.3.2.3p3). The statement

	if(pointer) statement1 else statement2

pointer will compare equal to 0 if pointer is null, causing statement2
to be executed, and unequal to 0 if pointer is not null, causing
statement1 to be executed. Compare this with the statement

	if(pointer!=NULL) statement1 else statement2

which evaluates pointer!=NULL, with a result that is either 0 if the
pointer is a null pointer, in which case it compares equal to 0 and
statement2 executes, or it produces 1 if pointer is not null, which does
not compare equal to 0, so statement1 is executed. In other words, it's
exactly equivalent to the previous if-statement, and any decent compiler
will generate essentially identical machine code, either way.

Some people prefer the pointer!=NULL form, as being clearer, but I've
been programming in C since 1979, so both forms look equally clear to
me, and the if(pointer) form is simpler. To me, if you think that
if(pointer!=NULL) is clearer, shouldn't if((pointer!=NULL)!=0) be even
clearer? And if so, wouldn't if(((pointer!=NULL)!=0)!=0) be even
clearer? However, many expert C programmer remain unconvinced by that
argument - so feel free to use whichever form you prefer.

> My confusion is about the 'started' variable.
> 
> #include <stdio.h>
>  int main()
> {
>     float latitude;
>     float longitude;
>     char info[80];
>     int started = 0; /**"We need to begin with "started" set       
>                      to 0, which means false."**/
> 
>     puts("data=[");
> 
>     while (scanf("%f,%f,%79[^\n]", , , ) == 3) 
>    {
>           if (started)
>               printf(",\n"); /**"You'll display a comma only if you've
>                              already displayed a previous line.**/
>           else
>               started = 1; /** "Once the loop has started, you can
>                             set "started" to 1, which is true.**/

The first time through the while loop, started is 0, which compares
equal to 0. Therefore, the else-clause "started = 1;" is executed. As a
result, the second time through the loop, started is already 1, which
does not compare equal to 0, so the if-clause "printf(",\n");" is
executed. The value of 'started' never changes back to zero, so it
continues doing the same thing in all subsequent passes through the loop.

>           printf("{latitude: %f, longitude: %f, info: '%s'}", , , );
>    }
> 
>    puts("\n]");
> 
>    return 0;
> }

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

#73718

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> Some people prefer the pointer!=NULL form, as being clearer, but I've
> been programming in C since 1979, so both forms look equally clear to
> me, and the if(pointer) form is simpler. To me, if you think that
> if(pointer!=NULL) is clearer, shouldn't if((pointer!=NULL)!=0) be even
> clearer?

Not at all.  I find `if (pointer != NULL)` clearer than `if (pointer)`
because the `!= NULL` makes it clear at a glance that it's a pointer
comparison.  We're checking whether `pointer` is unequal to a null
pointer, not to 0, 0.0, or '\0'.  (And in most real-world code, pointer
variables aren't named "pointer".)

Certainly C lets you use an expression of any scalar (arithmetic or
pointer) type as a condition, but I prefer to do so only for values that
are logically boolean -- either they're of type _Bool, or they're being
used that way, so that there's no logical distinction among any non-zero
values.  Which means that if, for example, `done` is a logically boolean
value, I would write `while (!done)`, never `while (done == false)`.

(I learned Pascal before I learned C; that probably influenced me.)

>          And if so, wouldn't if(((pointer!=NULL)!=0)!=0) be even
> clearer? However, many expert C programmer remain unconvinced by that
> argument - so feel free to use whichever form you prefer.

Indeed.

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

#73745

On Saturday, October 24, 2015 at 2:02:20 PM UTC-5, Keith Thompson wrote:
> Not at all.  I find `if (pointer != NULL)` clearer than `if (pointer)`
> because the `!= NULL` makes it clear at a glance that it's a pointer
> comparison.  We're checking whether `pointer` is unequal to a null
> pointer, not to 0, 0.0, or '\0'.  (And in most real-world code, pointer
> variables aren't named "pointer".)

In expressions like "if (ptr != null)" or "if ((foo & 1)!= 0)" I consider
the "null" and "0" to be "phony literals", since what the expressions are
really seeking to evaluate is the validity of ptr or the "zero-ness"
of (foo & 1).  While I appreciate that directly interpreting pointers or
integers as true/false values is hokey, I regard phony literals as being
somewhat hokey as well.

When testing a pointer against null, one isn't really interested in
comparing the pointer matches a null pointer, but whether it's valid.  The
fact that there is only one testable representation for a valid pointer
is coincidental.  Likewise in the expression for testing whether a number
is odd, the goal is not to see whether the value yielded by the bitwise
operator happens to match the number zero, but rather whether the two
operands have any bits in common; again, the fact that there's one
particular value which will be returned when they don't is coincidental
to the purpose of the expression.

If one were designing a language from scratch, it would probably make sense
to have an operator to explicitly test whether something is null, or to
test whether two values have any bits in common, but given that C implicitly
regards null pointers and zeroes as "false" and other pointers and integer
values as "true", there probably isn't a huge need for such things on modern
systems (though on a sign-magnitude system I could see a use for the special
bit-wise operator, since if one wanted to test whether a number was either
negative or odd, the expression "if (num & -1)" wouldn't be problematic for
negative even numbers, since even though -0 would have a bit set it would
still be considered "false").

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

#73746

supercat@casperkitty.com writes:
> On Saturday, October 24, 2015 at 2:02:20 PM UTC-5, Keith Thompson wrote:
>> Not at all.  I find `if (pointer != NULL)` clearer than `if (pointer)`
>> because the `!= NULL` makes it clear at a glance that it's a pointer
>> comparison.  We're checking whether `pointer` is unequal to a null
>> pointer, not to 0, 0.0, or '\0'.  (And in most real-world code, pointer
>> variables aren't named "pointer".)
>
> In expressions like "if (ptr != null)" or "if ((foo & 1)!= 0)" I consider
> the "null" and "0" to be "phony literals", since what the expressions are

You mean NULL, not null.

> really seeking to evaluate is the validity of ptr or the "zero-ness"
> of (foo & 1).  While I appreciate that directly interpreting pointers or
> integers as true/false values is hokey, I regard phony literals as being
> somewhat hokey as well.
>
> When testing a pointer against null, one isn't really interested in
> comparing the pointer matches a null pointer, but whether it's valid.

No, if I write `if (ptr != NULL)`, I'm testing whether ptr is unequal to
the null pointer.  If it's equal to NULL, it's because that's the most
recent value I stored in it.  I might also be *interested* in knowing
whether it's valid, but I have no way of testing that, so I don't
bother.

> The fact that there is only one testable representation for a valid pointer
> is coincidental.

I disagree; there's nothing coincidental about it.  `if (ptr)` and
`if (ptr != NULL)` are semantically identical.  The latter expresses
my intent more clearly.

[...]

> If one were designing a language from scratch, it would probably make sense
> to have an operator to explicitly test whether something is null, or to
> test whether two values have any bits in common, but given that C implicitly
> regards null pointers and zeroes as "false" and other pointers and integer
> values as "true", there probably isn't a huge need for such things on modern
> systems (though on a sign-magnitude system I could see a use for the special
> bit-wise operator, since if one wanted to test whether a number was either
> negative or odd, the expression "if (num & -1)" wouldn't be problematic for
> negative even numbers, since even though -0 would have a bit set it would
> still be considered "false").

If I were designing a language from scratch, rather than having some
special operator to test whether a pointer is null, I'd just define
equality for pointers and a constant whose value is a null pointer --
and not permit pointer values to be used directly as conditions.  I've
used several languages that work that way.  If you happen to prefer the
way C does it, that's fine; I'm merely expressing my preference.

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

#73747

On Sunday, October 25, 2015 at 12:29:17 AM UTC+1, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > On Saturday, October 24, 2015 at 2:02:20 PM UTC-5, Keith Thompson wrote:
> >> Not at all.  I find `if (pointer != NULL)` clearer than `if (pointer)`
> >> because the `!= NULL` makes it clear at a glance that it's a pointer
> >> comparison.  We're checking whether `pointer` is unequal to a null
> >> pointer, not to 0, 0.0, or '\0'.  (And in most real-world code, pointer
> >> variables aren't named "pointer".)
> >
> > In expressions like "if (ptr != null)" or "if ((foo & 1)!= 0)" I consider
> > the "null" and "0" to be "phony literals", since what the expressions are
> 
> You mean NULL, not null.
> 
> > really seeking to evaluate is the validity of ptr or the "zero-ness"
> > of (foo & 1).  While I appreciate that directly interpreting pointers or
> > integers as true/false values is hokey, I regard phony literals as being
> > somewhat hokey as well.
> >
> > When testing a pointer against null, one isn't really interested in
> > comparing the pointer matches a null pointer, but whether it's valid.
> 
> No, if I write `if (ptr != NULL)`, I'm testing whether ptr is unequal to
> the null pointer.  If it's equal to NULL, it's because that's the most
> recent value I stored in it.  I might also be *interested* in knowing
> whether it's valid, but I have no way of testing that, so I don't
> bother.
> 
> > The fact that there is only one testable representation for a valid pointer
> > is coincidental.
> 
> I disagree; there's nothing coincidental about it.  `if (ptr)` and
> `if (ptr != NULL)` are semantically identical.  The latter expresses
> my intent more clearly.
> 
> [...]
> 
> > If one were designing a language from scratch, it would probably make sense
> > to have an operator to explicitly test whether something is null, or to
> > test whether two values have any bits in common, but given that C implicitly
> > regards null pointers and zeroes as "false" and other pointers and integer
> > values as "true", there probably isn't a huge need for such things on modern
> > systems (though on a sign-magnitude system I could see a use for the special
> > bit-wise operator, since if one wanted to test whether a number was either
> > negative or odd, the expression "if (num & -1)" wouldn't be problematic for
> > negative even numbers, since even though -0 would have a bit set it would
> > still be considered "false").
> 
> If I were designing a language from scratch, rather than having some
> special operator to test whether a pointer is null, I'd just define
> equality for pointers and a constant whose value is a null pointer --
> and not permit pointer values to be used directly as conditions.  I've
> used several languages that work that way.  If you happen to prefer the
> way C does it, that's fine; I'm merely expressing my preference.
> 
The real problem is that NULL is too shouty, whilst 0 is too easily
confused with an integer counter. If it were null or nil then I'd
agree.

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

#73749

On Saturday, October 24, 2015 at 6:45:16 PM UTC-5, Malcolm McLean wrote:
> On Sunday, October 25, 2015 at 12:29:17 AM UTC+1, Keith Thompson wrote:
> > If I were designing a language from scratch, rather than having some
> > special operator to test whether a pointer is null, I'd just define
> > equality for pointers and a constant whose value is a null pointer --
> > and not permit pointer values to be used directly as conditions.  I've
> > used several languages that work that way.  If you happen to prefer the
> > way C does it, that's fine; I'm merely expressing my preference.
> > 
> The real problem is that NULL is too shouty, whilst 0 is too easily
> confused with an integer counter. If it were null or nil then I'd
> agree.

That problem in turn stems from the fact the lack of a keyword for null.
There is a very strong and wise convention that preprocessor macros are
written in ALLCAPS, since they do not obey the normal rules of scope,
and an attempt to use the name of an identifier in an inner scope may
sometimes throw any kind of meaningful semantics out the window.

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

#73748

On Saturday, October 24, 2015 at 6:29:17 PM UTC-5, Keith Thompson wrote:
> > When testing a pointer against null, one isn't really interested in
> > comparing the pointer matches a null pointer, but whether it's valid.
> 
> No, if I write `if (ptr != NULL)`, I'm testing whether ptr is unequal to
> the null pointer.  If it's equal to NULL, it's because that's the most
> recent value I stored in it.  I might also be *interested* in knowing
> whether it's valid, but I have no way of testing that, so I don't
> bother.

If code written in Standard C is to have any hope of working right, the
pointer must either be valid or null.  Attempting an rvalue conversion on
an invalid pointer would invoke Undefined Behavior even before the
comparison could be performed, and even in compilers where pointers
continue to identify storage locations and the relationships among them
regardless of whether anything owns the storage in question, there is
seldom much call to compare a possibly-invalid pointer against null.  It
is far more common that a pointer is guaranteed to either be valid or
null.


> > The fact that there is only one testable representation for a valid pointer
> > is coincidental.

> I disagree; there's nothing coincidental about it.  `if (ptr)` and
> `if (ptr != NULL)` are semantically identical.  The latter expresses
> my intent more clearly.

Different people parse things differently; I consider both to be idiomatic
and don't have any problem with either, though I never use the NULL macro
[I don't even remember offhand whether it's in stdlib.h or elsewhere].

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

#73750

supercat@casperkitty.com writes:
> On Saturday, October 24, 2015 at 6:29:17 PM UTC-5, Keith Thompson wrote:
>> > When testing a pointer against null, one isn't really interested in
>> > comparing the pointer matches a null pointer, but whether it's valid.
>> 
>> No, if I write `if (ptr != NULL)`, I'm testing whether ptr is unequal to
>> the null pointer.  If it's equal to NULL, it's because that's the most
>> recent value I stored in it.  I might also be *interested* in knowing
>> whether it's valid, but I have no way of testing that, so I don't
>> bother.
>
> If code written in Standard C is to have any hope of working right, the
> pointer must either be valid or null.  Attempting an rvalue conversion on
> an invalid pointer would invoke Undefined Behavior even before the
> comparison could be performed, and even in compilers where pointers
> continue to identify storage locations and the relationships among them
> regardless of whether anything owns the storage in question, there is
> seldom much call to compare a possibly-invalid pointer against null.  It
> is far more common that a pointer is guaranteed to either be valid or
> null.

All that is true, and none if it refutes anything I've said.  Was it
intended to?

>> > The fact that there is only one testable representation for a valid
>> > pointer is coincidental.
>
>> I disagree; there's nothing coincidental about it.  `if (ptr)` and
>> `if (ptr != NULL)` are semantically identical.  The latter expresses
>> my intent more clearly.
>
> Different people parse things differently; I consider both to be idiomatic
> and don't have any problem with either, though I never use the NULL macro
> [I don't even remember offhand whether it's in stdlib.h or elsewhere].

I also consider both to be idiomatic.  I simply prefer the more explicit
form, for reasons I've explained.

It's defined in <locale.h>, <stddef.h>, <stdio.h>, <stdlib.h>,
<string.h>, <time.h>, and <wchar.h>.  <stddef.h> is in some sense the
primary location, but it's defined in every standard header that uses
null pointers.

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

#74096

Keith Thompson <kst-u@mib.org> writes:

> supercat@casperkitty.com writes:
>> On Saturday, October 24, 2015 at 2:02:20 PM UTC-5, Keith Thompson wrote:
>>> Not at all.  I find `if (pointer != NULL)` clearer than `if (pointer)`
>>> because the `!= NULL` makes it clear at a glance that it's a pointer
>>> comparison.  We're checking whether `pointer` is unequal to a null
>>> pointer, not to 0, 0.0, or '\0'.  (And in most real-world code, pointer
>>> variables aren't named "pointer".)
>>
>> In expressions like "if (ptr != null)" or "if ((foo & 1)!= 0)" I consider
>> the "null" and "0" to be "phony literals", since what the expressions are
>
> You mean NULL, not null.

I'm writing a response to portions of two different messages,
which are given one after the other in the quoted text.  Probably
not all the quoted text needs to be included but it seemed better
to have too much than to potentially lose context.  Response is
at the end.

>> really seeking to evaluate is the validity of ptr or the "zero-ness"
>> of (foo & 1).  While I appreciate that directly interpreting pointers or
>> integers as true/false values is hokey, I regard phony literals as being
>> somewhat hokey as well.
>>
>> When testing a pointer against null, one isn't really interested in
>> comparing the pointer matches a null pointer, but whether it's valid.
>
> No, if I write `if (ptr != NULL)`, I'm testing whether ptr is unequal to
> the null pointer.  If it's equal to NULL, it's because that's the most
> recent value I stored in it.  I might also be *interested* in knowing
> whether it's valid, but I have no way of testing that, so I don't
> bother.
>
> [snip partially replicated portion (appears below)]
>
>> If one were designing a language from scratch, it would probably make sense
>> to have an operator to explicitly test whether something is null, or to
>> test whether two values have any bits in common, but given that C implicitly
>> regards null pointers and zeroes as "false" and other pointers and integer
>> values as "true", there probably isn't a huge need for such things on modern
>> systems (though on a sign-magnitude system I could see a use for the special
>> bit-wise operator, since if one wanted to test whether a number was either
>> negative or odd, the expression "if (num & -1)" wouldn't be problematic for
>> negative even numbers, since even though -0 would have a bit set it would
>> still be considered "false").
>
> If I were designing a language from scratch, rather than having some
> special operator to test whether a pointer is null, I'd just define
> equality for pointers and a constant whose value is a null pointer --
> and not permit pointer values to be used directly as conditions.  I've
> used several languages that work that way.  If you happen to prefer the
> way C does it, that's fine;  I'm merely expressing my preference.

[here starts the second message]
Keith Thompson <kst-u@mib.org> writes:

> supercat@casperkitty.com writes:
>> On Saturday, October 24, 2015 at 6:29:17 PM UTC-5, Keith Thompson wrote:
>>>
>>>> The fact that there is only one testable representation for a valid
>>>> pointer is coincidental.
>>>
>>> I disagree;  there's nothing coincidental about it.  `if (ptr)` and
>>> `if (ptr != NULL)` are semantically identical.  The latter expresses
>>> my intent more clearly.
>>
>> Different people parse things differently;  I consider both to be idiomatic
>> and don't have any problem with either, though I never use the NULL macro
>
> I also consider both to be idiomatic.  I simply prefer the more explicit
> form, for reasons I've explained.

It was reading this very last phrase that prompted me to go back
and look at the earlier comments more closely.  On doing that I
didn't come away with very much.  What you're saying strikes me
as mostly just circular - you prefer the explicit form because it
makes the pointerness more explicit.  As an explanation that
isn't very satisfying.  Can you say it another way?  What I think
you mean is that putting in the "!= NULL" part conveys more
information, with the unstated assumption that the extra information
is (in these cases) always valuable.  Does this comment capture,
or at least largely capture, what you're trying to express?  If
it doesn't, can you say more about what that is?

Assuming that my rephrasing above is more or less on the money,
I would like to offer another viewpoint.  In most cases I would
not include an explicit comparison for pointers (either to NULL
or to 0) because it doesn't tell me anything I don't already
know.  For example, compare

   if(p && *p != 0) ...

   if(p != NULL && *p != 0) ...

I don't need the "!= NULL", because it's obvious that the
variable p is a pointer.  Furthermore I would argue that
routinely using "!= NULL" (or "== NULL") everywhere is actually
harmful, because using it everywhere will lessen the impact in
those places where it really is important to emphasize the
pointerness.  If we use "!= NULL" to convey the information that
the thing being compared is a pointer -- which usually isn't very
much information -- we give up the possibility of using "!= NULL"
to convey other information that the writer might want to
express, and which can be a lot more significant.

I agree that doing an explicit comparision (eg, "!= NULL") can
sometimes be an aid to helping code be easier to read and
understand.  But I think it is wrong to conclude that therefore
there should be a rule for doing so always.

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

#74098

On 10/28/2015 2:16 PM, Tim Rentsch wrote:
> [...] In most cases I would
> not include an explicit comparison for pointers (either to NULL
> or to 0) because it doesn't tell me anything I don't already
> know.  For example, compare
>
>     if(p && *p != 0) ...
>
>     if(p != NULL && *p != 0) ...

     Why not

	if (p && *p) ...

?  If your objection to `== NULL' is that it tells you nothing
new, why does that same objection not also apply to `!= 0'?
If you reply that `p' is a pointer but `*p' is not, I ask
why a "zero" pointer should be treated differently from any
other kind of zero.  (I also observe that from the fragment
shown we cannot prove that `*p' is not a pointer!)

>[...]
> I agree that doing an explicit comparision (eg, "!= NULL") can
> sometimes be an aid to helping code be easier to read and
> understand.  But I think it is wrong to conclude that therefore
> there should be a rule for doing so always.

     Fine.  The most important rule about rules is that rules
should sometimes be broken.  We make rules to be our servants,
not to be our masters.  Others may make rules to master us, but
they'll be the first against the wall when the Revolution comes.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#74160

On Wed, 2015-10-28, Eric Sosman wrote:
> On 10/28/2015 2:16 PM, Tim Rentsch wrote:
>> [...] In most cases I would
>> not include an explicit comparison for pointers (either to NULL
>> or to 0) because it doesn't tell me anything I don't already
>> know.  For example, compare
>>
>>     if(p && *p != 0) ...
>>
>>     if(p != NULL && *p != 0) ...
>
>      Why not
>
> 	if (p && *p) ...
>
> ?  If your objection to `== NULL' is that it tells you nothing
> new, why does that same objection not also apply to `!= 0'?
> If you reply that `p' is a pointer but `*p' is not, I ask
> why a "zero" pointer should be treated differently from any
> other kind of zero.

If his mind works like mine: a zero pointer is always a special case,
associated with negative things like "invalid", "error", "false", "not
found" and "the end".  For int, char and so on, it depends entirely on
what they represent: sometimes 0 is special, sometimes it's not.

/Jorgen

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

[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