public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: GCC's statement expression extension
@ 2000-07-27 19:29 Richard Kenner
  2000-07-27 19:39 ` Jeffrey A Law
  2000-07-27 20:14 ` Mark Mitchell
  0 siblings, 2 replies; 104+ messages in thread
From: Richard Kenner @ 2000-07-27 19:29 UTC (permalink / raw)
  To: mark; +Cc: gcc

    If SPEC really contains invalid code, then we're between a rock and a
    hard place.  I don't think we should break the compiler just to
    compile a benchmark.  We could patch SPEC, and we can provide the
    patch to whomever we're allowed to, under the SPEC licenses.

Well the amusing part is that the piece of SPEC that won't compile is
GCC!  Indeed, both GCC 2.8.1 and the last pre-EGCS FSF codebase won't
compile with the latest GCC.

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-08-04  5:39 Mark Kettenis
  2000-08-04  9:06 ` Mark Mitchell
  0 siblings, 1 reply; 104+ messages in thread
From: Mark Kettenis @ 2000-08-04  5:39 UTC (permalink / raw)
  To: gcc, mark

   From: Jamie Lokier <egcs@tantalophile.demon.co.uk> 
   Date: Fri, 4 Aug 2000 13:35:25 +0200 

   [Mark: the toupper example is not correct]

Indeed, please read on.

   Here is an example using Glibc's <bits/string2.h> implementation of
   strcmp.  (Work through the mass of __builtin_constant_p to the
   __strcmp_cg call).

     printf ("%s", (!strcmp ("yes", (a+b).c_str())) ? "equal" : "not equal");

Note that glibc leaves out a lot of its optimizations that use
statement expressions for C++.  Among these are tolower and toupper
(which are inlines for C++), and all of the string optimizations in
bits/string.h and bits/string2.h.

The only macro's that use statement expressions in <string.h> that are
used for C++ are strdupa and strndupa.  And these look to me as things
that would be impossible to implement using inlines.

Mark, please make sure that what you're saying about glibc in the
documentation is accurate.  Feel free to keep the comment if you can
find a *real* example where the semantics are problematic.  Otherwise,
replace the reference to the GNU C Library with a concrete example of
a statement expression that has problems.

Mark

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-08-03 16:48 John Marshall
  2000-08-03 16:55 ` Mark Mitchell
  0 siblings, 1 reply; 104+ messages in thread
From: John Marshall @ 2000-08-03 16:48 UTC (permalink / raw)
  To: gcc

> RCS file: /cvs/gcc/egcs/gcc/extend.texi,v
[...]
> + string a, b;
> + printf("%s", toupper((a+b).c_str()[0]));
            ^^
            %c

    John

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-08-03 14:32 Mike Stump
  2000-08-04  4:36 ` Jamie Lokier
  0 siblings, 1 reply; 104+ messages in thread
From: Mike Stump @ 2000-08-03 14:32 UTC (permalink / raw)
  To: egcs; +Cc: gcc, mark, per

> Date: Thu, 3 Aug 2000 19:55:01 +0200
> From: Jamie Lokier <egcs@tantalophile.demon.co.uk>
> To: Mike Stump <mrs@windriver.com>

>   printf("%s", toupper((a+b).c_str()[0]));

Nope, not a problem.  You need one that takes and returns the same
char *, ah, answered my own question:

printf("%s", strcat((a+b).c_str(), ""));

But even in this case, strcat I bet isn't a macro, and even it it
were, I bet it would not abuse SEs, and even if it did, catting in ""
wouldn't make any sense.

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-08-02 13:44 Mike Stump
  2000-08-03 10:55 ` Jamie Lokier
  0 siblings, 1 reply; 104+ messages in thread
From: Mike Stump @ 2000-08-02 13:44 UTC (permalink / raw)
  To: mark; +Cc: gcc, per

> To: mrs@windriver.com
> Cc: per@bothner.com, gcc@gcc.gnu.org
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Tue, 01 Aug 2000 21:52:07 -0700

> Since this does not work correctly in C++, can we agree that this
> usage should be removed from glibc when compiling C++?

Yes.

> Also, can we add a note to the documentation section on
> statement-expressions in C++ giving this example, and explaining how
> it can surprise C++ users, so that people who go read about this
> extension in C will at least be aware that there are issues with
> this extension in C++?

Sure.

printf("%s", bad_c_marco((a+b).c_str()));

would be the canonical example, but I don't know of a libc function to
put here that uses SEs.

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-08-01 18:14 Mike Stump
  2000-08-01 21:52 ` Mark Mitchell
  2000-08-02 16:59 ` Alexandre Oliva
  0 siblings, 2 replies; 104+ messages in thread
From: Mike Stump @ 2000-08-01 18:14 UTC (permalink / raw)
  To: mark, per; +Cc: gcc

> To: per@bothner.com
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Sat, 29 Jul 2000 10:42:58 -0700

> That seems like the obvious right answer.  It just doesn't work very
> well for:

>   X x;
>   X f();

>   x = ({ f(); });

It seems like it does to me.  There is a preexisting references extend
the life of temporaries rule already in the C++ standard that I think
covers one sensible way to treat this case.  With that, it make
perfect sense to me.  It is true, that we have to realize that rule
`fits' in this situation, I see that as obvious.

> Oops.  The return value of f() got destroyed before we got a chance to
> copy it.  (There are more complex examples with similar problems,
> including binding things to references, which cause lifetime
> extensions in C++.)

It seems like the same issue to me.

> To: Mark Mitchell <mark@codesourcery.com>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 29 Jul 2000 15:47:26 -0300

> I see.  We'd have to have copied it to some temporary that would
> hold the result of the statement expression before calling its
> destructor.

A copy ctor to another temporary is another way to think about this.
This also fits, though, at first blush I think less well than
extending the lifetime.  Though, there might be technical reasons that
cause one to want to mandate a copy, and then permit the compiler to
get it of it, if it can.

> To: Mark Mitchell <mark@codesourcery.com>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 29 Jul 2000 16:29:53 -0300

> How about, for a start, mandating that the result of a statement
> expression be a POD object?  This would get us rid of the problem of
> handling destructors

I don't see a problem handling destructors.  I think the inside temps
expire at their full expression within the statements, and the object
that escapes from the expression in the expression statement has its
lifetime extended.  Simple, easy, consistent, predictable and in the
spirit of the standard.

> To: aoliva@redhat.com
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Sat, 29 Jul 2000 12:52:41 -0700

> There are other problems too:

>   #define foo(X) ({ /* some code */ f(X); /* some more code */ })

> Now, suppose that X is an expression that creates temporaries, and
> that `foo' is a standard library function.  (I've seen this with the
> glibc headers by the way.  Some of them do something like:

>   #define foo(x) ({ int i = x; ... }) 

> which has this form.)

> Then, temporaries involved in the X expression are destroyed at the
> end of the statement-expression, which is earlier than the language
> says they should be.  We break conformant programs in this way.

I find the argument where a person misuses #defines and doesn't meet
the requirements of the standard and breaks conformant code this way,
while implementing parts of the standard, to be not very convincing.
They can misuse a good number of features to break user code already.

> That's another reason why this construct has such difficult semantics
> in C++.

I don't see it this way.

> To: Mark Mitchell <mark@codesourcery.com>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 29 Jul 2000 18:07:12 -0300

> On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

> > There's really no right answer -- the other answer is to wait
> > until the end of the enclosing full expression.

> It appears to me that this would solve all of the problems you've
> listed so far, and it seems reasonably sound to me.

I don't think it is reasonable.  The words in the standard say that
certainly by the time the statement containing an expression ends, the
temps are gone.  You cannot violate this rule without a very good
reason.

> To: aoliva@redhat.com
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Sun, 30 Jul 2000 10:06:06 -0700

> You can define the semantics any weird way you want, and given N
> problems you can probably come up with a semantics that solves all N
> of them.  What I don't think possible, unfortunately, is come up
> with semantics that are consistent, in the spirit of C++, and easy
> for users to understand, and will solve the N+1st problem.

I disagree.  What problems remain?

> It adds no additional power, it provides no additional cleanliness,
> affords no portability.  On the other hand, it has dubious
> semantics, at best, and is difficult to implement (especially when
> you consider using these things in default arguments.

What are the issues you don't like with regard to default arguments?

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-07-31  9:31 Phil Edwards
  0 siblings, 0 replies; 104+ messages in thread
From: Phil Edwards @ 2000-07-31  9:31 UTC (permalink / raw)
  To: torvalds; +Cc: gcc

Linus Torvalds <torvalds@transmeta.com>:
[beyond-the-standards argument]
> Now, that does NOT mean that every extension should be considered a good
> one. I'm not arguing anything like that. But I do think that your
> standpoint that "it is an extension so it must be bad" is narrow-minded
> and ultimately stupid. Extensions must be judged on _other_ criteria.

I'm all for extensions for languages, as long as their default mode is off.
But the "extension == bad" criterion isn't the one being applied here.
One of the other criteria of which you speak is "does it even make sense
to do this, and can we do it in a rational manner?"

Statement expressions mostly fail that criterion for C++.  Certainly it can
be argued that it makes sense to add S.E. to C++ (I would argue against it,
but at least both sides have an arguement).  I don't think it can be done
in a way that works well; the rules for C++ are a bit more complicated
than those of C.

And as others have pointed out, adding S.E. to C gains you something.
Adding them to C++ gains you nothing, but costs you something.  At least,
adding them /in their present form/.


> But I do understand the problem: if you want to make statement expressions
> illegal in C++ (which I have no real opinion of - it's a language I don't
> care for), you're screwing up one of the original advantages of C++: the
> backwards compatibility with a language I _do_ care about, and one that I
> want to see live on rather than die the horrid death of being forever
> entomed in the cobwebs of standardization.

Not a valid argument, sorry.  C++ has as one of its goals backwards
compatibility with C.  It's not required to be sideways compatible with
things added to C (like, say, some of the stuff added to C99) after the fact.

If glibc wants to be useable under two languages, then it has to restrain
itself to the common denominator.


> Could somebody explain why C++ has so many problems with statement
> expressions? Maybe there is some solution to this - something that might
> involve a form of statement expression-like behaviour that works on both C
> and C++?

A bunch of the "technical reasons why not" have been hashed out on the
list since your message.  As far as a middle ground... hmm.  I like the
idea of improving on S.E. so that they're acceptable to both languages.
The semantics for S.E. under C++ are still just going to be ass-nasty
however they work.  Maybe some variation on the C99 inline functions.

And I suspect that the glibc headers would still have to be rewritten,
because some people like to write portable code, and use "-ansi -pedantic"
to help test for GCC-isms.  The glibc implementation, of course, could be
written purely in extensions and it wouldn't bother anybody.


Phil

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-07-30  3:49 Richard Kenner
  0 siblings, 0 replies; 104+ messages in thread
From: Richard Kenner @ 2000-07-30  3:49 UTC (permalink / raw)
  To: wilson; +Cc: gcc

From wilson@cygnus.com Fri Jul 28 00:24:22 2000
Received: from alpha2.ultra.nyu.edu by vlsi1.ultra.nyu.edu (4.1/1.34)
	id AA18487; Fri, 28 Jul 00 00:24:22 EDT
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5])
	by alpha2.ultra.nyu.edu (8.9.3/8.9.3) with ESMTP id AAA31914
	for <kenner@vlsi1.ultra.nyu.edu>; Fri, 28 Jul 2000 00:02:44 -0400 (EDT)
Received: from wilson.cygnus.com (wilson.cygnus.com [205.180.230.158])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA00201;
	Thu, 27 Jul 2000 21:11:14 -0700 (PDT)
From: Jim Wilson <wilson@cygnus.com>
Received: (wilson@localhost) by wilson.cygnus.com (8.9.3/8.6.4) id VAA21071; Thu, 27 Jul 2000 21:11:32 -0700
Date: Thu, 27 Jul 2000 21:11:32 -0700
Message-Id: < 200007280411.VAA21071@wilson.cygnus.com >
To: kenner@vlsi1.ultra.nyu.edu
Subject: Re: GCC's statement expression extension
Newsgroups: cygnus.egcs
In-Reply-To: < 10007280259.AA18359@vlsi1.ultra.nyu.edu >
Cc: gcc@gcc.gnu.org
Status: RO

In article < 10007280259.AA18359@vlsi1.ultra.nyu.edu > you write:
>    I suspect it is the obstacks use of ({ ... }) and ?: omitting the
>    middle argument in gcc 1.35.  
>
>Nope.  It's an error in bc-typecd.def.  Something about a float being
>promoted to double.

It is SPEC92 that contains gcc 1.35, and SPEC92 was obsoleted 5 years ago
when SPEC95 came out.  Anyone who cares about SPEC only cares about SPEC2000
now.  SPEC95 had gcc 2.5.3.  I haven't looked at SPEC2000 yet, but I would
be surprised if it didn't have at least gcc 2.7.2.

By the way, it is SPEC95 that has the bc-typecd.def problem, not SPEC92.
The erroneous code (and yes, it is invalid code) appears within a
#ifdef __GNUC__, so it is only gcc that could possibly fail to compile this
program.  And this isn't the only problem with this old code.  It isn't
64-bit clean either.  I had to fix several bugs to get it working on an
ia64-linux machine.  None of these problems justify changing how we
develop gcc.

Jim

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-07-28 13:08 Kaveh R. Ghazi
  2000-07-28 13:45 ` Mark Mitchell
  0 siblings, 1 reply; 104+ messages in thread
From: Kaveh R. Ghazi @ 2000-07-28 13:08 UTC (permalink / raw)
  To: mark; +Cc: gcc

 > From: Mark Mitchell <mark@codesourcery.com>
 > 
 > >>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
 > 
 >     Kaveh> Mark,
 > 
 >     Kaveh> 	As I see it, you're only proposing removing stmt exprs
 >     Kaveh> from G++.  The blocking factor is glibc's use of them in
 >     Kaveh> headers to optimize things like the string functions.  I
 >     Kaveh> don't have access to my linux box at the
 > 
 > Oh, no!  Your access went away right in the middle of that sentence!

:-)  Sorry.

I was going to say...

I don't have access to my linux box at the moment, but IIRC don't the
glibc headers have a way, via a cpp macro or something, to turn off
use of the replacement string macros that use stmt exprs and back down
to function calls?  (__NO_STRING_INLINES?)

If so, we can just teach g++ to always pass -D__NO_STRING_INLINES to
cpp to make sure the appropriate magic happens to turn off these stmt
expr using macros and then you can safely take out stmt exprs from
G++.

I don't know if all stmt exprs were protected using wrappers macros
though.  E.g. I don't think strdupa() was macro wrapped.

	 Anyway, just a thought...

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-07-28 12:14 Kaveh R. Ghazi
  2000-07-28 12:22 ` Mark Mitchell
  0 siblings, 1 reply; 104+ messages in thread
From: Kaveh R. Ghazi @ 2000-07-28 12:14 UTC (permalink / raw)
  To: mark; +Cc: gcc

 > From: Mark Mitchell <mark@codesourcery.com>
 > 
 > Folks --
 > 
 >   We've now degenerated (largely my fault!) into complete
 > abstraction.  Fun, but useless.
 > 
 >   We all agree that breaking compatibility (source or binary) is bad.
 > I hope we all agree that *sometimes* it is the best path -- if it
 > permits better optimizations, better stability, faster release cycles,
 > etc.  We have to take each of these things case by case; there's no
 > other way.

Mark,

	As I see it, you're only proposing removing stmt exprs from
G++.  The blocking factor is glibc's use of them in headers to
optimize things like the string functions.  I don't have access to my
linux box at the 

^ permalink raw reply	[flat|nested] 104+ messages in thread
* RE: GCC's statement expression extension
@ 2000-07-28 12:01 Anjul Srivastava
  2000-07-28 12:11 ` Gabriel Dos Reis
  2000-07-28 13:33 ` sidster
  0 siblings, 2 replies; 104+ messages in thread
From: Anjul Srivastava @ 2000-07-28 12:01 UTC (permalink / raw)
  To: 'Linus Torvalds', Marc Espie; +Cc: gcc

It does not have undefined behavior, and will always evaluate to: three plus
twice the old value of i.

But that's besides the point. Even if you consider: ++i + i++ the behavior
is undefined,

but it cannot format your hard disk and still remain conforming. It cannot
ever return 42, regardless of the value of i. (It can only return an odd
integer but this again is besides the point).

The C/C++ standards leave only the order of evaluation undefined. They say
that of the possible choices of order of evaluation, which one is selected
is undefined. But the fact that one of them is selected is mandated by the
standard. That's why 42 is out, and formatting the hard disk is out, as also
returning 43 when the value of i is 5 is not possible unless you violate the
standard.

-----Original Message-----
From: Linus Torvalds [ mailto:torvalds@transmeta.com ]

Think about a basic C (and C++) expression:

	++i + ++i

What does the C standard say about the above?

Right. It has undefined behavior. It can return 42. It can format your
harddisk. And the compiler is still strictly conforming, and yes, you get
the occasional "bug-report" about it, but everybody agrees that it _is_
undefined behaviour, and everybody even agrees on _why_ it is undefined
behaviour, and there is really no problem.

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-07-27 19:46 Richard Kenner
  2000-07-27 21:11 ` Jim Wilson
  0 siblings, 1 reply; 104+ messages in thread
From: Richard Kenner @ 2000-07-27 19:46 UTC (permalink / raw)
  To: meissner; +Cc: gcc

    I suspect it is the obstacks use of ({ ... }) and ?: omitting the
    middle argument in gcc 1.35.  

Nope.  It's an error in bc-typecd.def.  Something about a float being
promoted to double.

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-07-27 19:20 Richard Kenner
  2000-07-27 19:26 ` Mark Mitchell
  0 siblings, 1 reply; 104+ messages in thread
From: Richard Kenner @ 2000-07-27 19:20 UTC (permalink / raw)
  To: mark; +Cc: gcc

    One of the saving graces here is that older versions of the compiler
    are always available.  

True, but that's why the SPEC example is so interesting.  The current
version of GCC cannot compile SPEC and I don't think it's acceptable
to say "well, we can get SPEC numbers on the older versions, so it
doesn't matter that we can't get it on the latest compiler".

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-07-27 18:41 Richard Kenner
  2000-07-27 19:15 ` Mark Mitchell
  0 siblings, 1 reply; 104+ messages in thread
From: Richard Kenner @ 2000-07-27 18:41 UTC (permalink / raw)
  To: mark; +Cc: gcc

    Your opinions are valuable.  Although I think you may not fully
    understand the C++ user base.  

I'm talking about *C* not C++. As you point out, I know nothing about the
latter user base.

    On the other hand, the arguments Michael makes apply to almost any
    extension, and I do not agree, by any means, that we must preserve all
    extensions for all time.  The same argument justifies preserving many
    bugs; every time we issue an error that we did not before, we break
    programs.

Sure, and that is indeed a problem.  For example, the latest sources cannot
compile the GCC that has part of SPEC due to a new error message.

With as large a user base as we have, we cannot afford to ignore these issues
and if we try to, we'll surely hear about it.

^ permalink raw reply	[flat|nested] 104+ messages in thread
* Re: GCC's statement expression extension
@ 2000-07-27 18:24 Richard Kenner
  2000-07-27 18:38 ` Mark Mitchell
  0 siblings, 1 reply; 104+ messages in thread
From: Richard Kenner @ 2000-07-27 18:24 UTC (permalink / raw)
  To: meissner; +Cc: gcc

    Speaking for the users, I would argue that removal of statement
    expressions, even in C++ only, is a supremely bad idea.  I would
    hesitate to guess how many people use these features right now, but I
    would be willing to bet it more than the people reading this mailing
    list.  Misdesigned or not, it is an incredibly useful feature, and
    people use it.  Even if there are better ways of doing it, won't
    change all of the extant code out in the world.  

I *strongly* agree

^ permalink raw reply	[flat|nested] 104+ messages in thread
* GCC's statement expression extension
@ 2000-07-21 16:31 Joseph S. Myers
  2000-07-23  9:39 ` Jeffrey A Law
  0 siblings, 1 reply; 104+ messages in thread
From: Joseph S. Myers @ 2000-07-21 16:31 UTC (permalink / raw)
  To: gcc

GCC has the "statement expression" extension, where a compound statement
may be enclosed in parentheses and used as part of an expression, ({
... }).

It seems GCC does not restrict gotos in and out of statement expressions,
even where they don't particularly make sense.  For example, the
nonsensical program

	#include <stdio.h>
	int main(void){ printf ("%d\n", ({a:; 0; })); goto a; }

dumps core for me on i686-pc-linux-gnu (after printing 0 many times).

Is there any use for such jumps, or should this extension have a
constraint (in standards terminology) that a program shall not jump into a
statement expression from outside (with a mandatory error)?

Do jumps out of statement expressions work sensibly in GCC either (i.e.,
not crash, but with unspecified semantics relating to what of the
containing expression, except where subject to sequence point rules, has
been evaluated)?

Does GCC define the sequence point semantics of statement
expressions?  (For example, may evaluation of multiple statement
expressions within one containing expression be interleaved, cf the ruling
for DR#087 against the old C standard that function calls do not overlap?)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

^ permalink raw reply	[flat|nested] 104+ messages in thread

end of thread, other threads:[~2000-08-05 12:03 UTC | newest]

Thread overview: 104+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-27 19:29 GCC's statement expression extension Richard Kenner
2000-07-27 19:39 ` Jeffrey A Law
2000-07-27 19:45   ` Michael Meissner
2000-07-27 20:16     ` Mark Mitchell
2000-07-27 20:50       ` Michael Meissner
2000-07-27 20:57         ` Jim Wilson
2000-07-27 21:25         ` Mark Mitchell
2000-07-27 20:14 ` Mark Mitchell
  -- strict thread matches above, loose matches on Subject: below --
2000-08-04  5:39 Mark Kettenis
2000-08-04  9:06 ` Mark Mitchell
2000-08-03 16:48 John Marshall
2000-08-03 16:55 ` Mark Mitchell
2000-08-03 14:32 Mike Stump
2000-08-04  4:36 ` Jamie Lokier
2000-08-04  9:04   ` Mark Mitchell
2000-08-04  9:26     ` Jamie Lokier
2000-08-04 13:19       ` Mark Mitchell
2000-08-02 13:44 Mike Stump
2000-08-03 10:55 ` Jamie Lokier
2000-08-03 16:13   ` Mark Mitchell
2000-08-04 12:38     ` Kamil Iskra
2000-08-04 13:24       ` Mark Mitchell
2000-08-05 11:56         ` Kamil Iskra
2000-08-05 12:03           ` Mark Mitchell
2000-08-01 18:14 Mike Stump
2000-08-01 21:52 ` Mark Mitchell
2000-08-02 16:59 ` Alexandre Oliva
2000-08-02 21:01   ` Per Bothner
2000-07-31  9:31 Phil Edwards
2000-07-30  3:49 Richard Kenner
2000-07-28 13:08 Kaveh R. Ghazi
2000-07-28 13:45 ` Mark Mitchell
2000-07-28 12:14 Kaveh R. Ghazi
2000-07-28 12:22 ` Mark Mitchell
2000-07-28 12:01 Anjul Srivastava
2000-07-28 12:11 ` Gabriel Dos Reis
2000-07-28 13:33 ` sidster
2000-07-27 19:46 Richard Kenner
2000-07-27 21:11 ` Jim Wilson
2000-07-27 19:20 Richard Kenner
2000-07-27 19:26 ` Mark Mitchell
2000-07-30 12:09   ` Linus Torvalds
2000-07-27 18:41 Richard Kenner
2000-07-27 19:15 ` Mark Mitchell
2000-07-28  3:59   ` Marc Espie
2000-07-28  8:11     ` Mark Mitchell
2000-08-02 15:00   ` Kamil Iskra
2000-08-02 15:14     ` Mo McKinlay
2000-08-02 15:18     ` Mark Mitchell
2000-07-27 18:24 Richard Kenner
2000-07-27 18:38 ` Mark Mitchell
2000-07-27 19:21   ` Michael Meissner
2000-07-27 21:15     ` Jim Wilson
2000-07-28  7:31       ` Michael Meissner
2000-07-28  9:08         ` Nick Ing-Simmons
2000-07-28  9:19           ` Gabriel Dos Reis
2000-07-28  9:37             ` Nick Ing-Simmons
2000-07-27 23:53   ` Gabriel Dos Reis
2000-07-28 12:08   ` Stan Shebs
2000-07-28 12:16     ` Gabriel Dos Reis
2000-07-28 13:07       ` Stan Shebs
2000-07-28 12:28     ` Mark Mitchell
2000-07-28 14:08       ` Stan Shebs
2000-07-28 17:49         ` llewelly
2000-07-28 22:54           ` Mark Mitchell
2000-07-28 22:40         ` Mark Mitchell
2000-07-29 10:28           ` Per Bothner
2000-07-29 10:43             ` Mark Mitchell
2000-07-29 11:48               ` Alexandre Oliva
2000-07-29 12:09                 ` Mark Mitchell
2000-07-29 12:30                   ` Alexandre Oliva
2000-07-29 12:52                     ` Mark Mitchell
2000-07-29 14:07                       ` Alexandre Oliva
2000-07-30 10:06                         ` Mark Mitchell
2000-07-30  9:29                   ` Per Bothner
2000-07-30 11:23                 ` Linus Torvalds
2000-07-29 18:00               ` Per Bothner
2000-07-29 16:20         ` Marc Espie
2000-07-21 16:31 Joseph S. Myers
2000-07-23  9:39 ` Jeffrey A Law
2000-07-23  9:52   ` Mark Mitchell
2000-07-24 15:48     ` Geoff Keating
2000-07-25  8:44       ` Mark Mitchell
2000-07-26 21:25       ` Richard Henderson
2000-07-26 21:24     ` Richard Henderson
2000-07-26 21:38       ` Mark Mitchell
2000-07-26 22:51         ` Linus Torvalds
2000-07-27 21:14           ` Marc Espie
2000-07-27 21:28             ` Mark Mitchell
2000-07-27 21:29             ` Mo McKinlay
2000-07-28  0:45               ` Akbar A.
2000-07-28  7:27               ` Michael Meissner
2000-07-28 11:50             ` Linus Torvalds
2000-07-28 21:14               ` Marc Espie
2000-07-28 21:28                 ` Linus Torvalds
2000-07-29  1:40                   ` Marc Espie
2000-07-30 10:21                     ` Linus Torvalds
2000-07-27  4:34         ` Joseph S. Myers
2000-07-27  4:53           ` Gabriel Dos Reis
2000-07-27  9:42           ` Mark Mitchell
2000-07-27 17:32             ` Michael Meissner
2000-07-27 14:51           ` Alexandre Oliva
2000-07-29 10:41         ` Per Bothner
2000-07-29 14:36           ` Jamie Lokier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).