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

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

Unspecified Behaviors in C90 - part 3

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

Contents

  Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 11:21 -0700
    Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:54 -0400
      Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 21:38 +0100
    Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-13 21:22 +0000
      Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:21 -0700
        Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-14 08:48 -0700
          Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 09:33 -0700
            Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 18:08 +0100
              Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:38 -0700
                Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 00:47 -0400
                  Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:10 -0700
                    Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:17 -0400
                    Re: Unspecified Behaviors in C90 - part 3 maddoxr@acm.org - 2015-07-17 07:43 -0700
                Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 09:35 +0100
                  Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:18 -0700
                    Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:45 +0100
                    Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:19 -0400
                      Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-17 12:14 -0400
                        Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-17 11:00 -0700
                    Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:24 +0000
                Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-16 07:40 -0700
                  Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:20 -0700
                    Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:49 +0100
            Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-14 11:23 -0700
            Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-14 15:11 -0400
              Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:46 -0700
                Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 01:50 -0400
                  Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:15 -0700
                    Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:39 +0100
                    Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 22:26 -0400
        Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:22 +0000
        Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-19 17:57 -0400

Page 2 of 2 — ← Prev page 1 [2]

#65702

David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
>> On 14/07/15 17:33, David Kleinecke wrote:
[...]
>> > On the other hand the order of evaluation of arguments needs to be
>> > documented because perhaps the order is predictable.
>> 
>> If the order is predictable, you don't need to document it because you 
>> can just predict it instead. In fact, the order is not predictable (in 
>> the sense that more than one reasonable choice can be made and 
>> implementers do in fact make different choices on occasion), but it 
>> turns out not to matter because well-written C code doesn't depend on 
>> order of evaluation (between sequence points).
>
> What about
>     y = f(g(x),h(x));
> where g and h have different non-commutive side-effects on something 
> else? Say g(x) = {y=y+2} and h(x) = {y=3*y}

He said *well-written* C code.  That isn't.

If you care about the order in which g(x) and h(x) are executed,
you need to write code that guarantees their order of execution.

Even if a compiler vendor took your advice and documented the order,
the behavior of the code would still vary from one implementation
to another.

[...]

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

#65734

On Thursday, July 16, 2015 at 7:41:10 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
> >> On 14/07/15 17:33, David Kleinecke wrote:
> [...]
> >> > On the other hand the order of evaluation of arguments needs to be
> >> > documented because perhaps the order is predictable.
> >> 
> >> If the order is predictable, you don't need to document it because you 
> >> can just predict it instead. In fact, the order is not predictable (in 
> >> the sense that more than one reasonable choice can be made and 
> >> implementers do in fact make different choices on occasion), but it 
> >> turns out not to matter because well-written C code doesn't depend on 
> >> order of evaluation (between sequence points).
> >
> > What about
> >     y = f(g(x),h(x));
> > where g and h have different non-commutive side-effects on something 
> > else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
> 
> He said *well-written* C code.  That isn't.
> 
> If you care about the order in which g(x) and h(x) are executed,
> you need to write code that guarantees their order of execution.
> 
> Even if a compiler vendor took your advice and documented the order,
> the behavior of the code would still vary from one implementation
> to another.
 
No more than any two implementations with different extensions.

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

#65742

On 17/07/15 01:20, David Kleinecke wrote:
> On Thursday, July 16, 2015 at 7:41:10 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Tuesday, July 14, 2015 at 10:09:00 AM UTC-7, Richard Heathfield wrote:
>> >> On 14/07/15 17:33, David Kleinecke wrote:
>> [...]
>> >> > On the other hand the order of evaluation of arguments needs to be
>> >> > documented because perhaps the order is predictable.
>> >>
>> >> If the order is predictable, you don't need to document it because you
>> >> can just predict it instead. In fact, the order is not predictable (in
>> >> the sense that more than one reasonable choice can be made and
>> >> implementers do in fact make different choices on occasion), but it
>> >> turns out not to matter because well-written C code doesn't depend on
>> >> order of evaluation (between sequence points).
>> >
>> > What about
>> >     y = f(g(x),h(x));
>> > where g and h have different non-commutive side-effects on something
>> > else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
>>
>> He said *well-written* C code.  That isn't.
>>
>> If you care about the order in which g(x) and h(x) are executed,
>> you need to write code that guarantees their order of execution.
>>
>> Even if a compiler vendor took your advice and documented the order,
>> the behavior of the code would still vary from one implementation
>> to another.
>
> No more than any two implementations with different extensions.


That's precisely why those who need to write portable code are loath to 
use extensions - because the behaviour of those extensions can and will 
differ from one compiler to another (or may not even exist on other 
compilers). If you write code that uses extensions, you hurt the 
portability of your program. If you write code that relies on a 
particular evaluation order, again you hurt the portability of your program.

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

#65577

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> On the other hand the order of evaluation of arguments needs to be
> documented because perhaps the order is predictable. 

No, the order of evaluation doesn't need to be documented.
That's why it isn't.

> A blanket statement is too simple but brief statements will usually
> suffice. 

A blanket statement (in this case, that the order of evaluation
of function arguments is unspecified) is exactly as simple as it
needs to be.  That statement is already in the C standard, and
does not need to be repeated in an implementation's documentation.
No more information than that is necessary, and a requirement to
provide such information would impose an unreasonable burden on
implementers with little or no corresponding benefit either to
implementers or to programmers.

Nothing prevents implementers from providing such documentation,
and if it were useful to users there would be market pressure for
them to do so.

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

#65580

On 07/14/2015 12:33 PM, David Kleinecke wrote:
...
> On the other hand the order of evaluation of arguments needs to be
> documented because perhaps the order is predictable. 

So? With an modern compiler with an aggressive optimizer, by far the
quickest way to predict what order will be used would be to compile the
program, and find out which order was actually used by examining the
generated program.

But let's assume for the moment that it is possible to provide a simple
accurate statement of how the order is determined - what use would that
be? One of the key reasons for making the order unspecified is to
discourage people from writing code where the order matters. If it does
matter, explicitly evaluate all but one of the arguments in the order
that you want, storing the results in temporary variables, and then pass
those variables as arguments. That's much clearer, and the order is
guaranteed.

If you follow those guidelines, what value would you gain from being
able to read documentation of the actual order?

> A blanket statement is too simple but brief statements will usually
> suffice. 

We're not asking for a blanket statement - if there were valid
justification for mandating documentation of all those items, I'd expect
it be a very different justification for each item.

However, brief statements won't be sufficient, either - at least, not if
those are examples of what you mean by "brief statements". They are far
too brief, and don't really work, either.
-- 
James Kuyper

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

#65673

On Tuesday, July 14, 2015 at 12:11:39 PM UTC-7, James Kuyper wrote:
> On 07/14/2015 12:33 PM, David Kleinecke wrote:
> ...
> > On the other hand the order of evaluation of arguments needs to be
> > documented because perhaps the order is predictable. 
> 
> So? With an modern compiler with an aggressive optimizer, by far the
> quickest way to predict what order will be used would be to compile the
> program, and find out which order was actually used by examining the
> generated program.
 
But if the order matters the optimizer msut respect it or it is in
error. 

> But let's assume for the moment that it is possible to provide a simple
> accurate statement of how the order is determined - what use would that
> be? One of the key reasons for making the order unspecified is to
> discourage people from writing code where the order matters. If it does
> matter, explicitly evaluate all but one of the arguments in the order
> that you want, storing the results in temporary variables, and then pass
> those variables as arguments. That's much clearer, and the order is
> guaranteed.

That describes the function model I prefer. Functions have at most one
argument and that argunment is usually (always?) a pointer to a struct
where the arguments are placed. This can be done now simply by coding 
that way. 

Assuming I am not allowed to meddle with library I am obligated to wrap 
most of the library functions - not too much of a task. 

 
> If you follow those guidelines, what value would you gain from being
> able to read documentation of the actual order?
> 
> > A blanket statement is too simple but brief statements will usually
> > suffice. 
> 
> We're not asking for a blanket statement - if there were valid
> justification for mandating documentation of all those items, I'd expect
> it be a very different justification for each item.
> 
> However, brief statements won't be sufficient, either - at least, not if
> those are examples of what you mean by "brief statements". They are far
> too brief, and don't really work, either.
> -- 
> James Kuyper

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

#65685

On 07/15/2015 10:46 PM, David Kleinecke wrote:
> On Tuesday, July 14, 2015 at 12:11:39 PM UTC-7, James Kuyper wrote:
...
>> So? With an modern compiler with an aggressive optimizer, by far the
>> quickest way to predict what order will be used would be to compile the
>> program, and find out which order was actually used by examining the
>> generated program.
>  
> But if the order matters the optimizer msut respect it or it is in
> error. 

No - if the order is specified, the optimizer must respect it, or it is
in error. If the order matters, but is not specified, it's the code
that's in error, not the optimizer. The code is in error by reason of
failing to specify the desired order. The C language provides all the
constructs you need to force things to be evaluated in a specific order,
if the order matters - all you have to do is use the right constructs.
Example: if it's important that f() be executed before g(), don't write

	a = f() + g();

That would constitute a failure on your part to tell the compiler that
the order is important. Here's how to tell it that:

	temp = f();
	a = temp + g();

-- 
James Kuyper

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

#65732

On Wednesday, July 15, 2015 at 10:50:40 PM UTC-7, James Kuyper wrote:
> On 07/15/2015 10:46 PM, David Kleinecke wrote:
> > On Tuesday, July 14, 2015 at 12:11:39 PM UTC-7, James Kuyper wrote:
> ...
> >> So? With an modern compiler with an aggressive optimizer, by far the
> >> quickest way to predict what order will be used would be to compile the
> >> program, and find out which order was actually used by examining the
> >> generated program.
> >  
> > But if the order matters the optimizer msut respect it or it is in
> > error. 
> 
> No - if the order is specified, the optimizer must respect it, or it is
> in error. 

That (apart for the "no") is exactly what I said. We are getting into
pointless squabbles about trivia.

If the order matters, but is not specified, it's the code
> that's in error, not the optimizer. The code is in error by reason of
> failing to specify the desired order. The C language provides all the
> constructs you need to force things to be evaluated in a specific order,
> if the order matters - all you have to do is use the right constructs.
> Example: if it's important that f() be executed before g(), don't write
> 
> 	a = f() + g();
> 
> That would constitute a failure on your part to tell the compiler that
> the order is important. Here's how to tell it that:
> 
> 	temp = f();
> 	a = temp + g();

But suppose the compiler already did that but failed to tell you.

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

#65740

On 17/07/15 01:15, David Kleinecke wrote:
> On Wednesday, July 15, 2015 at 10:50:40 PM UTC-7, James Kuyper wrote:
>> On 07/15/2015 10:46 PM, David Kleinecke wrote:
>> > On Tuesday, July 14, 2015 at 12:11:39 PM UTC-7, James Kuyper wrote:
>> ...
>> >> So? With an modern compiler with an aggressive optimizer, by far the
>> >> quickest way to predict what order will be used would be to compile the
>> >> program, and find out which order was actually used by examining the
>> >> generated program.
>> >
>> > But if the order matters the optimizer msut respect it or it is in
>> > error.
>>
>> No - if the order is specified, the optimizer must respect it, or it is
>> in error.
>
> That (apart for the "no") is exactly what I said. We are getting into
> pointless squabbles about trivia.

No, there is a slight but very significant difference. You wrote "if the 
order matters". He wrote "if the order is specified". Those are not the 
same thing. If the order doesn't matter, it doesn't matter. If it does 
matter, though, it's *your* job (as things stand at present) to ensure 
that things happen in the right order - and that's as it should be. (In 
fact, even if the order of evaluation were specified, it would still be 
your job - it's just that your job will be marginally easier if the 
evaluation order matches the order that you write the code, and 
marginally harder otherwise). James is saying that *if* the 
implementation were required to specify its order of evaluation, *then* 
it would be required to honour that spec.

It is not a trivial distinction. It is a very important distinction.

>
>> If the order matters, but is not specified, it's the code
>> that's in error, not the optimizer. The code is in error by reason of
>> failing to specify the desired order. The C language provides all the
>> constructs you need to force things to be evaluated in a specific order,
>> if the order matters - all you have to do is use the right constructs.
>> Example: if it's important that f() be executed before g(), don't write
>>
>> 	a = f() + g();
>>
>> That would constitute a failure on your part to tell the compiler that
>> the order is important. Here's how to tell it that:
>>
>> 	temp = f();
>> 	a = temp + g();
>
> But suppose the compiler already did that but failed to tell you.

Then you've lost nothing, and in fact you've gained clarity of 
expression. It's a better program, and it will survive a port to a 
compiler that /doesn't/ do that.

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

#65749

On 07/16/2015 08:15 PM, David Kleinecke wrote:
> On Wednesday, July 15, 2015 at 10:50:40 PM UTC-7, James Kuyper wrote:
>> On 07/15/2015 10:46 PM, David Kleinecke wrote:
>>> On Tuesday, July 14, 2015 at 12:11:39 PM UTC-7, James Kuyper wrote:
>> ...
>>>> So? With an modern compiler with an aggressive optimizer, by far the
>>>> quickest way to predict what order will be used would be to compile the
>>>> program, and find out which order was actually used by examining the
>>>> generated program.
>>>  
>>> But if the order matters the optimizer msut respect it or it is in
>>> error. 
>>
>> No - if the order is specified, the optimizer must respect it, or it is
>> in error. 
> 
> That (apart for the "no") is exactly what I said. We are getting into
> pointless squabbles about trivia.

No, I said something quite different from what you said, and you've
missed the distinction I made. If the order is specified [by the
standard[, the optimizer must respect it. If the order matters [to you],
the optimizer has no obligation to respect it.

> If the order matters, but is not specified, it's the code
>> that's in error, not the optimizer. The code is in error by reason of
>> failing to specify the desired order. The C language provides all the
>> constructs you need to force things to be evaluated in a specific order,
>> if the order matters - all you have to do is use the right constructs.
>> Example: if it's important that f() be executed before g(), don't write
>>
>> 	a = f() + g();
>>
>> That would constitute a failure on your part to tell the compiler that
>> the order is important. Here's how to tell it that:
>>
>> 	temp = f();
>> 	a = temp + g();
> 
> But suppose the compiler already did that but failed to tell you.

When you write a = f() + g(), one possibility is that the compiler
generated code equivalent to the code I gave above. The other
possibility is that it generated the equivalent of

	temp = g();
	a = f() + temp;

The compiler will generate whichever of the two versions of that code
that it likes best, generally the one that executes fastest, though
there are other reasons why it might favor one over the other. In this
case, f() and g() appear to have identical interfaces, so it probably
doesn't matter, but in more complicated cases they might have different
argument lists and different return types, in which case the order might
make a big difference. Leaving implementations free to chose the best
order in such cases is part of the reason why the order is left unspecified.

Do you care whether f() is called before g()? Then tell the compiler
that you care, by using whichever of the two versions given above
matches the order that you want.
If you don't care whether f() is called before g(), then write a = f() +
g(), because that gives the compiler more freedom to optimize your code.
-- 
James Kuyper

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

#65926

David Kleinecke <dkleinecke@gmail.com> wrote:

> On Monday, July 13, 2015 at 2:22:53 PM UTC-7, Richard Bos wrote:
> > David Kleinecke <dkleinecke@gmail.com> wrote:
> > 
> > > Appendix G.1 to the 1990 ISO Standard lists 22 unspecified behaviors
> > > recognized by the standard.  These behaviors are of interest because 
> > > an implementation of C is not required to document them.
> > 
> > No, you keep getting this wrong.
> > 
> > These behaviours are unspecified precisely because they are _not_ of
> > interest to the programmer. Note that this is stronger than "you need
> > not care about this": it's closer to "you _should_ not care about this".
> > If you start delving into the details of unspecified behaviour, you are
> > on a hiding to nothing; worse, you are setting yourself up to be trapped
> > by over-optimisations that break.
>  
> I agree. The confusing part seems to be that people jump to the
> conclusion that documentation means a full description. All the
> documentation needs to say is that "this cannot be depended on"
> or words to that effect. 

That is what you have now. What the _FUCK_ more are you asking for?

Richard

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

#65935

On 07/14/2015 11:21 AM, David Kleinecke wrote:
> On Monday, July 13, 2015 at 2:22:53 PM UTC-7, Richard Bos wrote:
...
>> These behaviours are unspecified precisely because they are _not_ of
>> interest to the programmer. Note that this is stronger than "you need
>> not care about this": it's closer to "you _should_ not care about this".
>> If you start delving into the details of unspecified behaviour, you are
>> on a hiding to nothing; worse, you are setting yourself up to be trapped
>> by over-optimisations that break.
>  
> I agree. The confusing part seems to be that people jump to the
> conclusion that documentation means a full description.

Sorry about this late response. I had a thought about that message that
didn't gel until long after I had read it, and I haven't had the time to
track it down since then. Richard Bos's recent response to this same
message made it easier to find.

The reason people "jump to th[at] conclusion" is because it's basically
correct, in the context of the C standard.

The standard defines implementation-defined behavior as "unspecified
behavior where each implementation documents how the choice is made".
There's a lot of things the standard doesn't say about this
documentation. It could be stored in a secure location, and it might
cost you a billion dollars to get permission to read it. The standard
doesn't require that the documentation be comprehensible to the reader.
It doesn't have to be written in any language the reader knows how to
read. It doesn't have to be in any language that any person still living
knows how to read :-). For that matter, it could be oral documentation,
recorded in English with a Russian accent so thick that even people who
were fluent in both languages would be unable to understand it.

However, despite all the things the standard doesn't say about the
documentation, it is implied that the documentation must be accurate: if
it's inaccurate, then what's been documented is something other than
"how the choice was made". It must be basically complete, any
incompleteness would mean that part of "how the choice was made" would
not be documented. If the language of the documentation is in fact one
that nobody knows how to read :-) , then there will be no way to
determine whether the implementation has met that part of its
conformance requirements  - but those requirements still apply.

There are exceptions to this. For instance, 5.2.4.2.2p6 says "The
implementation may state that the accuracy is unknown." There's an old
saying, the "the exception proves the rule", which is, of course,
nonsense according to modern English usage of those words. But a recent
discussion in this newsgroup revealed that the origin of the saying
could have been translated more accurately into modern English by saying
"The exception proves the existence of a rule".
In this case, 5.2.4.2.2p6 is an exception that implies that the general
rule is that the documentation required for implementation-defined
behavior is normally required to be complete - it must actually document
everything that the standard requires it to document. The only reason
it's allowed to wimp out on floating point accuracy is because the
standard makes an explicit exception for that case. No exception would
be needed if "X is unknown" was normally allowed as documentation for
everything.

So, you're suggesting that the standard should a) require that more
things be documented but b) should not require that the things which are
documented be meaningfully documented? While that would substantially
reduce the workload of implementors, what good would it do? If adopted
as a general principle, it implies that none of an implementation's
mandatory documentation need be complete. Do you really want to
encourage incomplete documentation? I thought that your basic
preferences were in the opposite direction.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web