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

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

sizeof environment variables array = 1?

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

Contents

  sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-08 11:13 -0400
    Re: sizeof environment variables array = 1? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-08 11:25 -0400
      Re: sizeof environment variables array = 1? Keith Thompson <kst-u@mib.org> - 2017-06-08 09:34 -0700
        Re: sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-08 13:14 -0400
          Re: sizeof environment variables array = 1? jameskuyper@verizon.net - 2017-06-08 10:51 -0700
    Re: sizeof environment variables array = 1? Gareth Owen <gwowen@gmail.com> - 2017-06-08 16:56 +0100
      Re: sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-08 12:18 -0400
        Re: sizeof environment variables array = 1? scott@slp53.sl.home (Scott Lurndal) - 2017-06-08 16:35 +0000
        Re: sizeof environment variables array = 1? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-08 12:43 -0400
          Re: sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-08 13:49 -0400
            Re: sizeof environment variables array = 1? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-08 13:58 -0400
              Re: sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-08 14:45 -0400
            Re: sizeof environment variables array = 1? Keith Thompson <kst-u@mib.org> - 2017-06-08 12:10 -0700
              Re: sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-09 11:21 -0400
              Re: sizeof environment variables array = 1? Richard Heathfield <rjh@cpax.org.uk> - 2017-06-09 16:23 +0100
                Re: sizeof environment variables array = 1? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-09 11:48 -0400
                  Re: sizeof environment variables array = 1? Richard Heathfield <rjh@cpax.org.uk> - 2017-06-09 16:53 +0100
                    Re: sizeof environment variables array = 1? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-09 12:18 -0400
                      Re: sizeof environment variables array = 1? Richard Heathfield <rjh@cpax.org.uk> - 2017-06-09 17:28 +0100
                  Re: sizeof environment variables array = 1? Keith Thompson <kst-u@mib.org> - 2017-06-09 09:12 -0700
                Re: sizeof environment variables array = 1? "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 09:28 +0200
            Re: sizeof environment variables array = 1? jak <please@nospam.tnx> - 2017-06-08 22:18 +0200
              Re: sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-08 17:31 -0400
                Re: sizeof environment variables array = 1? Keith Thompson <kst-u@mib.org> - 2017-06-08 15:12 -0700
                  Re: sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-09 11:21 -0400
                    Re: sizeof environment variables array = 1? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-09 16:39 +0100
                      Re: sizeof environment variables array = 1? Gareth Owen <gwowen@gmail.com> - 2017-06-10 07:26 +0100
                        Re: sizeof environment variables array = 1? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-10 13:21 +0100
                      Re: sizeof environment variables array = 1? gordonb.q80bx@burditt.org (Gordon Burditt) - 2017-06-10 17:32 -0500
                        Re: sizeof environment variables array = 1? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-11 01:01 +0100
                        Re: sizeof environment variables array = 1? luser droog <luser.droog@gmail.com> - 2017-06-11 01:28 -0700
                        Re: sizeof environment variables array = 1? raltbos@xs4all.nl (Richard Bos) - 2017-06-17 18:38 +0000
                    Re: sizeof environment variables array = 1? Keith Thompson <kst-u@mib.org> - 2017-06-09 08:41 -0700
                    Re: sizeof environment variables array = 1? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-09 11:50 -0400
                    Re: sizeof environment variables array = 1? raltbos@xs4all.nl (Richard Bos) - 2017-06-17 18:37 +0000
                      Re: sizeof environment variables array = 1? DFS <nospam@dfs.com> - 2017-06-18 09:11 -0400
            Re: sizeof environment variables array = 1? "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-06-10 09:19 +0200
        Re: sizeof environment variables array = 1? Robert Wessel <robertwessel2@yahoo.com> - 2017-06-08 12:44 -0500
      Re: sizeof environment variables array = 1? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-08 18:01 +0100
        Re: sizeof environment variables array = 1? Gareth Owen <gwowen@gmail.com> - 2017-06-08 18:45 +0100
      Re: sizeof environment variables array = 1? Keith Thompson <kst-u@mib.org> - 2017-06-08 11:51 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#111923

Le 09.06.2017 à 17:23, Richard Heathfield a écrit :
> On 08/06/17 20:10, Keith Thompson wrote:
>> And be careful with strncpy(); it's not just a "safer" version of
>> strcpy().
> 
> In fact, it's not /even/ a "safer" version of strcpy().
> 
>> (Usually the best way to be careful with it is to avoid using
>> it.)
> 
> Legitimate uses of strncpy are indeed rare. As you hint, however, we 
> lack a proof that they do not exist.
> 
I use it some times in Pro*C (the embedded SQL for Oracle databases). 
The VARCHAR fields are of fixed sizes and do not need to be nul 
terminated. To avoid to send crap to the DB using strncpy allows to copy 
the chars and clean the rest of the buffer in one function call.

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

#111859

Il 08/06/2017 19:49, DFS ha scritto:
> On 6/8/2017 12:43 PM, Lew Pitcher wrote:
>
>
>> but, I'd probably write it something like...
>>
>>    int envars;
>>
>>    /* advance through env[] array, looking for NULL pointer */
>>    for (envars = 0; env[envars] != NULL; ++envars) {/*NOP*/}
>>
>>    printf("%d\n",envars);
>
>
> I just want to extract the Path env variable.
>
> This code hangs.  Am I misusing strncpy?
>
> int envars=0;
> char tmp[5];
> for (envars = 0; env[envars] != NULL; ++envars)
> {
>     strncpy(tmp,env[envars],5);
>     tmp[5]='\0';
>     if (strcmp(tmp,"Path=")==0)
>     {
>         printf("%d. %s\n", envars+1, env[envars]);
>         break;
>     }
> }
>

Why don't you use the getenv fuction? It comes with standard libraries 
(stdio.h).

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

#111862

On 6/8/2017 4:18 PM, jak wrote:


> Why don't you use the getenv fuction? It comes with standard libraries 
> (stdio.h).


Thanks for the hint.

What I was wanting to do was check the Windows Path to see if they had 
the GNUWin32 packages installed.  It would be rare, but if they do have 
them I can use the 'file' command, same as on Linux.

On Linux I don't think I'll need to check the environ vars; the 'file' 
command is installed by default as far as I know.

I'll try getenv here on Windows.

Edit:  it's a few lines.

if (strstr(getenv("Path"),"string") != NULL)
printf("string found in Path\n");
else
printf("string not found in path\n");


Cool stuff.

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

#111865

DFS <nospam@dfs.com> writes:
> On 6/8/2017 4:18 PM, jak wrote:
>> Why don't you use the getenv fuction? It comes with standard libraries 
>> (stdio.h).
>
> Thanks for the hint.
>
> What I was wanting to do was check the Windows Path to see if they had 
> the GNUWin32 packages installed.  It would be rare, but if they do have 
> them I can use the 'file' command, same as on Linux.
>
> On Linux I don't think I'll need to check the environ vars; the 'file' 
> command is installed by default as far as I know.
>
> I'll try getenv here on Windows.
>
> Edit:  it's a few lines.
>
> if (strstr(getenv("Path"),"string") != NULL)
> printf("string found in Path\n");
> else
> printf("string not found in path\n");

You're still trying to use the "file" command for this?

There is no clear distinction between text files and binary files.
Invoking the "file" command (which may or may not be available) on
a file will not reliably tell you whether a file is text or binary.
The output of the "file" command is intended for human consumption,
and is not designed to be parseable (unless you ask it for the MIME
type, but even that is likely to be unsuitable for your purpose).

I think you have a classic XY problem <http://xyproblem.info/>.
Your underlying problem is to determine whether an input file is
valid for your program.  You've decided that the first step in
solving that problem is to determine whether the file is text or
binary, and you've been on a wild goose chase figuring out how to
do that.

Instead, I strongly suggest you define what constitutes valid input
for your program, and check for that.

What characters are acceptable?  Printable ASCII characters?
ASCII control characters?  Non-ASCII accented letters?  If the file
turns out to be valid, will you read it as text?  Are multibyte
characters acceptable?  Is there a maximum acceptable line length?
And so on.

For example, if I feed a binary file named "c.c" to gcc, it doesn't
check whether it's text or binary; it simply tries to parse it as
C source code and prints error messages if it fails.

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

#111880

On 6/8/2017 6:12 PM, Keith Thompson wrote:

> Instead, I strongly suggest you define what constitutes valid input
> for your program, and check for that.


'file' returns ASCII in the description, or the extension is .txt.

That's it.

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

#111883

DFS <nospam@dfs.com> writes:

> On 6/8/2017 6:12 PM, Keith Thompson wrote:
>
>> Instead, I strongly suggest you define what constitutes valid input
>> for your program, and check for that.
>
> 'file' returns ASCII in the description, or the extension is .txt.
>
> That's it.

On my system, file does not include the word ASCII on the description of
several files that I would consider to be text files (PDF files with
only ASCII characters, for example).

And if you accept any file with .txt extension, is there really any
point in checking anything else since a .txt file might conmtain
anything at all?

-- 
Ben.

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

#111918

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> On my system, file does not include the word ASCII on the description of
> several files that I would consider to be text files (PDF files with
> only ASCII characters, for example).

That's not an unreasonable definition of a text file, but I've never
seen or heard anyone use anything like it before.

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

#111927

Gareth Owen <gwowen@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> On my system, file does not include the word ASCII on the description of
>> several files that I would consider to be text files (PDF files with
>> only ASCII characters, for example).
>
> That's not an unreasonable definition of a text file, but I've never
> seen or heard anyone use anything like it before.

Sorry!  I typed PDF because I was doing something else at the time!  I
meant EPS -- encapsulated PostScript.  I think everyone agrees that these
are often just text files.

-- 
Ben.

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

#111948

> On my system, file does not include the word ASCII on the description of
> several files that I would consider to be text files (PDF files with
> only ASCII characters, for example).

One reasonable definition of a text file is that you can safely
"cat file" or "lpr file" to your terminal emulation without doing
nasty things to your terminal state such as changing fonts, invoking
reverse video and/or blinking and/or odd colors, changing screen
size, locking the keyboard, etc.  (Object files and executables
usually do some of these.)

I don't think PDF files qualify for that.  Although the text in a
PDF file might only contain ASCII characters and use only ASCII
fonts (but fonts embedded in a PDF are not represented in ASCII),
I don't believe there are any PDF files that contain only text
characters (particularly excluding NUL and ESC).  If the PDF file
also contains images, all bets are off.

I see later you corrected that to EPS.  That's Postscript source
code, and it is typically limited to printable ASCII text, but I'm
not sure it has to be (particularly if the document to be printed
has accented letters, Chinese, Japanese, or Korean characters, etc.

> And if you accept any file with .txt extension, is there really any
> point in checking anything else since a .txt file might conmtain
> anything at all?

It's very easy for a virus, or a simple error in understanding what
the output format is supposed to be, to result in a .txt file that
doesn't meet your expectations.

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

#111952

gordonb.q80bx@burditt.org (Gordon Burditt) writes:

>> On my system, file does not include the word ASCII on the description of
>> several files that I would consider to be text files (PDF files with
>> only ASCII characters, for example).
>
> One reasonable definition of a text file is that you can safely
> "cat file"

It was a typo.  I meant EPS file but was producing a PDF (for some
unrelated purpose) at the time and I typed what I was thinking about not
what I meant!

<snip>
-- 
Ben.

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

#111962

On Saturday, June 10, 2017 at 5:32:47 PM UTC-5, Gordon Burditt wrote:
> > On my system, file does not include the word ASCII on the description of
> > several files that I would consider to be text files (PDF files with
> > only ASCII characters, for example).
> 
> One reasonable definition of a text file is that you can safely
> "cat file" or "lpr file" to your terminal emulation without doing
> nasty things to your terminal state such as changing fonts, invoking
> reverse video and/or blinking and/or odd colors, changing screen
> size, locking the keyboard, etc.  (Object files and executables
> usually do some of these.)
> 
> I don't think PDF files qualify for that.  Although the text in a
> PDF file might only contain ASCII characters and use only ASCII
> fonts (but fonts embedded in a PDF are not represented in ASCII),
> I don't believe there are any PDF files that contain only text
> characters (particularly excluding NUL and ESC).  If the PDF file
> also contains images, all bets are off.
> 
> I see later you corrected that to EPS.  That's Postscript source
> code, and it is typically limited to printable ASCII text, but I'm
> not sure it has to be (particularly if the document to be printed
> has accented letters, Chinese, Japanese, or Korean characters, etc.

Your suspicions are correct. PS (and by extension EPS) can
and often will be ascii. But since the Level 2 standard of
1992, there are many standard ways of using binary data in
the stream. And even with level 1, you can just read binary
from the stream (assuming a binary channel) and interpret it
how you wish.

PDF can be mostly ascii or almost all binary, but never
completely ascii. There are byte-offset cross-references
which are in a strict byte format.

[OT -- too much postscript info below. Warning. ]

For interest, the several standard ways of using binary
in postscript are: binary tokens, binary object sequences
and maybe something else I forget.

Binary tokens are the basis of most of my postscript
golfing libary  https://github.com/luser-dr00g/G
By packing a code number into a binary-executable-name-
token fragment, operators can be called without using
their long names by number or even from strings.

Also, taking advantage of the fact that the binary 
executable name codes are encoded alphabetically, we
can iterate backwards through the list and easily
define the alphabetically shortest prefix for all
operators. With this shortcut, verbose ps code can
be abbreviated.

  1 2 ad 3 mu  6 di 0 mo
  0 0 mov
  10 10 lin
  strok
  showp

Consult PLRM, appendix F for full list of Encoded
System Names.

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

#112406

gordonb.q80bx@burditt.org (Gordon Burditt) wrote:

> I see later you corrected that to EPS.  That's Postscript source
> code, and it is typically limited to printable ASCII text, but I'm
> not sure it has to be (particularly if the document to be printed
> has accented letters, Chinese, Japanese, or Korean characters, etc.

This is just as true for .txt files in Unicode...

Richard

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

#111884

DFS <nospam@dfs.com> writes:
> On 6/8/2017 6:12 PM, Keith Thompson wrote:
>> Instead, I strongly suggest you define what constitutes valid input
>> for your program, and check for that.
>
> 'file' returns ASCII in the description, or the extension is .txt.
>
> That's it.

I don't believe the file command reads the entire file, so it might
report ASCII for something that contains non-ASCII characters.

On systems that support symbolic links, "file" on a symbolic link
just says it's a symbolic link; it doesn't report on the contents
of a file.  I would expect a symlink to a pure ASCII text file to
be acceptable, but you would reject it.  Unless the target of the
symlink happens to have the string ASCII in its name.

I can rename any binary file to give it a ".txt" extension.  If your
program is vulnerable to bad input, that's how someone can break it.

If those are your requirements, that's up to you -- but I don't
see how the requrements you've given make any sense.

There must be some logical basis for the requirements you've
stated, but if you're unwilling to discuss that basis (your *real*
requirements), we can't help you.

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

#111886

On 06/09/2017 11:21 AM, DFS wrote:
> On 6/8/2017 6:12 PM, Keith Thompson wrote:
>
>> Instead, I strongly suggest you define what constitutes valid input
>> for your program, and check for that.
>
>
> 'file' returns ASCII in the description, or the extension is .txt.
>
> That's it.

Why is that of concern to your program?
I strongly suspect that the relevant issue, whatever it is, is far more 
specific, and that you're better off checking for the relevant issue, 
than trying to check the output of "file".

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

#112405

DFS <nospam@dfs.com> wrote:

> On 6/8/2017 6:12 PM, Keith Thompson wrote:
> 
> > Instead, I strongly suggest you define what constitutes valid input
> > for your program, and check for that.
> 
> 'file' returns ASCII in the description, or the extension is .txt.
> 
> That's it.

What does your program do when it gets fed an executable that was
accidentally renamed .txt?
Why can your program not handle a Unicode text file with the extension
text?

Richard

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

#112457

On 6/17/2017 2:37 PM, Richard Bos wrote:
> DFS <nospam@dfs.com> wrote:
> 
>> On 6/8/2017 6:12 PM, Keith Thompson wrote:
>>
>>> Instead, I strongly suggest you define what constitutes valid input
>>> for your program, and check for that.
>>
>> 'file' returns ASCII in the description, or the extension is .txt.
>>
>> That's it.
> 
> What does your program do when it gets fed an executable that was
> accidentally renamed .txt?

Splits it into N files, each with the same number of lines (the last 
file might have a remainder # of lines).


> Why can your program not handle a Unicode text file with the extension
> text?

It can, after the extension is changed to txt (on Windows).


> Richard

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

#111922

Le 08.06.2017 à 19:49, DFS a écrit :
> On 6/8/2017 12:43 PM, Lew Pitcher wrote:
> 
> 
>> but, I'd probably write it something like...
>>
>>    int envars;
>>
>>    /* advance through env[] array, looking for NULL pointer */
>>    for (envars = 0; env[envars] != NULL; ++envars) {/*NOP*/}
>>
>>    printf("%d\n",envars);
> 
> 
> I just want to extract the Path env variable.
> 
> This code hangs.  Am I misusing strncpy?
> 
> int envars=0;
> char tmp[5];
> for (envars = 0; env[envars] != NULL; ++envars)
> {
>      strncpy(tmp,env[envars],5);
>      tmp[5]='\0';

Buffer overflow. offset 5 is out of bound. Declare tmp as tmp[6];

Furthermore, the strncpy function fills the buffer with 0 up to the 
given size, so you don't need the tmp[5]='\0';

Use also the sizeof operator, it knows the real size of you array. So if 
you change the declaration, you don't need to modify all the places in 
your code where you used the magic value.

strncpy(tmp, env[envars], sizeof tmp);

>      if (strcmp(tmp,"Path=")==0)
>      {
>          printf("%d. %s\n", envars+1, env[envars]);
>          break;
>      }
> }
> 

Another alternative of your code is to not copy the string and use 
another function strncmp

int envars=0;
for (envars = 0; env[envars] != NULL; ++envars)
{
     if (strncmp(env[envars], "Path=", 5)==0)
     {
         printf("%d. %s\n", envars+1, env[envars]);
         break;
     }
}

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

#111845

On Thu, 8 Jun 2017 12:18:32 -0400, DFS <nospam@dfs.com> wrote:

>On 6/8/2017 11:56 AM, Gareth Owen wrote:
>> DFS <nospam@dfs.com> writes:
>> 
>>> int main(int argc, char *argv[], char *env[])
>>> {
>>>    printf("%d\n",sizeof(env)/sizeof(env[0]));
>>>    return(0);
>>> )
>>>
>>> Output is 1.
>>>
>>> Why?
>> 
>> Anything that looks like an array object - when used in the argument
>> list of a function, is not an array object, but "decays" into a pointer.
>> 
>> so in
>> 
>> int foo(char *arr1[12])
>> {
>>     char *arr2[12];
>>     char **arr3;
>> }
>> 
>> arr1 and arr3 have the same type, even though
>> arr1 and arr2 have the same declaration.
>> 
>> A misfeature, but an explicable one.
>
>Gotcha
>
>
>> There is no way to obtain the size of arr1 in foo() without passing it
>> in explicitly (or counting them using a sentinel such as NULL to mark
>> the end, as is done with environment variables)
>
>I want to check the Path env variable for the existence of a string:
>
>\GNU\Win32\bin
>
>
>I counted the env variables:
>
>int envars=0;
>while (*env!=NULL) {*env++;envars++;}
>printf("%d\n",envars);
>65
>
>But then I can't go back and reference the values in env[] again because 
>the pointer has moved to the end of the array (or past it?).
>
>What would you suggest?
>
>1) can I reset the pointer back to the beginning of env[]?   How?


Without saving a copy, you can't.  While there are certainly times
when modifying the parameter of a function itself is useful, it's
probably something that should only be done with some care, since you
then lose the ability to access the original value, and in most cases,
people aren't expecting that.  Note: there are systems where the
original env pointer is available in some other fashion, but they're
not standard.


>2) make a copy of the env[] array and use it?  How do I make a copy?


No, that's probably not what you want to do.


>3) can I create a new pointer pointing back to the beginning of env[]?  How?


Instead of modifying env itself, either make a copy of env, and modify
that, or use a subscript to access the individual environment
variables.  IOW:

  char *myenv[];
  ...
  myenv=env;  /*as often as you'd like to go back to the beginning */

-or-

  printf("string#%i=%s\n", i, env[i]); /* modify i as you see fit */

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

#111839

Gareth Owen <gwowen@gmail.com> writes:

> DFS <nospam@dfs.com> writes:
>
>> int main(int argc, char *argv[], char *env[])
>> {
>>   printf("%d\n",sizeof(env)/sizeof(env[0]));

Technically %zu or cast the result to int, but don't worry: at least two
regular posters here (BartC and Rick C Hogin) wonder why anyone would
bother pointing this out.  You have their assurance that it will work.

>>   return(0);
>> )
>>
>> Output is 1.
>>
>> Why?
>
> Anything that looks like an array object - when used in the argument
> list of a function, is not an array object, but "decays" into a
> pointer.

"Anything that looks like an array" is too general, I think.  For some
people either of these:

  void f(int p1[][4], int (*p2)[4]);

might look like an array used in a parameter list.  The rules that it is
only "top-level" array types that are treated as pointer types -- if it
looks like array of T it is treated as to pointer to T.

<snip>
-- 
Ben.

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

#111846

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> "Anything that looks like an array" is too general, I think. ... if it
> looks like array of T it is treated as to pointer to T.

A totally valid distinction.  I was a bit woolly.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web