On Wed, Nov 16, 2005 at 09:15:33PM +0100, Gabriel Dos Reis wrote:
> Richard Henderson <[EMAIL PROTECTED]> writes:
>
> | On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
> | > | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
> | >
> | > That simply means GCC got it wrong.
Richard Henderson <[EMAIL PROTECTED]> writes:
| On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
| > | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
| >
| > That simply means GCC got it wrong.
|
| The world is not all C++, Gaby.
But that wasn't the point.
-- Gaby
On Sat, Nov 12, 2005 at 09:57:10PM +0100, Gabriel Dos Reis wrote:
> | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
>
> That simply means GCC got it wrong.
The world is not all C++, Gaby.
r~
> From: David Daney
> Sent: Tuesday, November 15, 2005 11:44 AM
> To: Mike Stump
> Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]
> Subject: Re: Null pointer check elimination
>
>
> Mike Stump wrote:
> > On Nov 14, 2005, at 11:36 PM, David Daney wrote:
> >
> >
Mike Stump wrote:
On Nov 14, 2005, at 11:36 PM, David Daney wrote:
Perhaps not in general, but one unstated premise of this whole thread
is that for some GCC targets (most Unix like operating systems) you
*can* count on a SIGSEGV when you dereference a null pointer.
Unless that null poin
There are several examples. One is converting from a derived class
to a base class when there is multiple inheritance. An offset must
be subtracted, unless it is a null pointer.
Why does it matter if the pointer is null? It is an error
in the program if it uses the result, but the same is true
On Nov 14, 2005, at 11:36 PM, David Daney wrote:
Perhaps not in general, but one unstated premise of this whole
thread is that for some GCC targets (most Unix like operating
systems) you *can* count on a SIGSEGV when you dereference a null
pointer.
Unless that null pointer points to an obj
On Mon, Nov 14, 2005 at 04:16:43PM -0800, Janis Johnson wrote:
> On Mon, Nov 14, 2005 at 11:56:16PM +0100, Gabriel Dos Reis wrote:
> > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
> > SEGFAULT is not a behaviour defined by the language. It is *just* one
> > form of undefined behaviour. If you e
Tom Tromey writes:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Bernd> Speaking of which, has anyone ported gcj to a MMU-less uClinux
> Bernd> platform yet?
>
> Andrew> It's impossible with the current config. This is because some of
> Andrew> libgcj is written on C++,
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
Bernd> Speaking of which, has anyone ported gcj to a MMU-less uClinux
Bernd> platform yet?
Andrew> It's impossible with the current config. This is because some of
Andrew> libgcj is written on C++, and the C++ compiler FE does not insert
> "David" == David Daney <[EMAIL PROTECTED]> writes:
David> The Java Language Specification requires that NullPointerExceptions
David> are thrown when calling a method via a null 'this'. But since a
David> method call does not usually involve dereferencing 'this', an explicit
David> check for
Bernd Schmidt writes:
> David Daney wrote:
> > Perhaps not in general, but one unstated premise of this whole thread is
> > that for some GCC targets (most Unix like operating systems) you *can*
> > count on a SIGSEGV when you dereference a null pointer. The java front
> > end takes advant
David Daney wrote:
Perhaps not in general, but one unstated premise of this whole thread is
that for some GCC targets (most Unix like operating systems) you *can*
count on a SIGSEGV when you dereference a null pointer. The java front
end takes advantage of this fact to eliminate explicit check
Gabriel Dos Reis wrote:
I'm saying that if you call foo with a null pointer, you get into
undefined behaviour territory. And GCC is founded to make
optimization based on that. And you -- as a user -- generally don't
know how and when GCC can apply that assumption. And it is already
doing so in
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | void bar(int& a);
| > | | void foo(int* a)
| > | {
| > | // dereference: conversion to reference
| > | // Since there is not necessarily any object access,
|
Maybe the middle end should only have one pointer type, but with at
least two attributes, one to tell the debugger to auto-dereference,
one to mark those pointers that cannot point to null. This might
enable more optimization.
That would certainly be my recommendation. It would a
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| void bar(int& a);
|
| void foo(int* a)
| {
| // dereference: conversion to reference
| // Since there is not necessarily any object access,
| // thus no assured SEGFAULT.
| bar(*a);
SEGFAULT is not a b
On Mon, Nov 14, 2005 at 11:56:16PM +0100, Gabriel Dos Reis wrote:
> "Michael N. Moran" <[EMAIL PROTECTED]> writes:
> SEGFAULT is not a behaviour defined by the language. It is *just* one
> form of undefined behaviour. If you execute that function, it might
> reformat your harddrive and that woud
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | From info gcc:
| > | | `-fdelete-null-pointer-checks'
| > | Use global dataflow analysis to identify and eliminate useless
| > | checks for null pointers.
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| From info gcc:
|
| `-fdelete-null-pointer-checks'
| Use global dataflow analysis to identify and eliminate useless
| checks for null pointers. The compiler assumes that dereferencing
| a null pointer wo
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | void buzz(Abc& b)
| > | {
| > | delete &b;
| > | }
| > | | void baz()
| > | {
| > | Abc& a = * new Abc();
| > If no memory is availa
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | Wow. I'm sure there is sound reasoning for this ... but I can't
| > | understand what that might be given a client module could intentionally
| > | (if ill-adviseadly)
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | void buzz(Abc& b)
| > | {
| > | delete &b;
| > | }
| > | | void baz()
| > | {
| > | Abc& a = * new Abc();
| > If no memory is available, the new-expression th
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Wow. I'm sure there is sound reasoning for this ... but I can't
| understand what that might be given a client module could intentionally
| (if ill-adviseadly) simply invoke the function:
then it gets what it deserves. Che
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| void buzz(Abc& b)
| {
| delete &b;
| }
|
| void baz()
| {
| Abc& a = * new Abc();
If no memory is available, the new-expression throws an exception so
the dereference never occurs. Check out C++ manuals.
As a
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
[...]
| Do we want to hide the error by not crashing? Why not just do the
| math and keep running? This seems like a run-time check that
| is not a part of the C/C++ language as I understand it.
defined by which standards?
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
| > On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
| >
| >>Excuse me. IANALL nor am I a compiler expert but ...
| >>what kind of optimization might be done with the information
| >>that a reference *should* never b
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | And what is the meaning of code that does this:
| > | | int foo(int& a)
| > | {
| > | int*b = &a;
| > | | if(b ==0)
| > | {
| > | a();
| > |
Joe Buck wrote:
On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
Excuse me. IANALL nor am I a compiler expert but ...
what kind of optimization might be done with the information
that a reference *should* never be null? Especially within
the server code (the implementation of "
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
[...]
| Do we want to hide the error by not crashing? Why not just do the
| math and keep running? This seems like a run-time check that
| is not a part of the C/C++ language as I understand it.
defined by which standards?
-- Gaby
Gabriel Dos Reis wrote:
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| And what is the meaning of code that does this:
|
| int foo(int& a)
| {
| int*b = &a;
|
| if(b ==0)
| {
| a();
| }
| else
| {
| b();
| }
According to the standar
Joe Buck wrote:
On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
Excuse me. IANALL nor am I a compiler expert but ...
what kind of optimization might be done with the information
that a reference *should* never be null? Especially within
the server code (the implementation of "
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| And what is the meaning of code that does this:
|
| int foo(int& a)
| {
| int*b = &a;
|
| if(b ==0)
| {
| a();
| }
| else
| {
| b();
| }
According to the standard, the compiler can assume t
On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
> Excuse me. IANALL nor am I a compiler expert but ...
> what kind of optimization might be done with the information
> that a reference *should* never be null? Especially within
> the server code (the implementation of "int f(int& a
Joe Buck wrote:
On Sat, Nov 12, 2005 at 04:01:07PM -0500, Andrew Pinski wrote:
Was there an example of:
int f(int &);
int g(void)
{
int *a = 0;
return f(*a);
}
Yes this would be undefined code but so what.
In a case like this, gcc could emit an error (since we can already
detect that a
On Sat, Nov 12, 2005 at 10:47:33AM -0800, Per Bothner wrote:
> Per Bothner wrote:
> >A "function-never-returns-null" attribute doesn't seem like
> >the right mechanism. Instead, there should be a "never-null"
> >attribute on pointer types. A "function-never-returns-null" is
> >just a function wh
On Sat, Nov 12, 2005 at 04:01:07PM -0500, Andrew Pinski wrote:
> Was there an example of:
>
> int f(int &);
>
> int g(void)
> {
> int *a = 0;
> return f(*a);
> }
>
>
> Yes this would be undefined code but so what.
In a case like this, gcc could emit an error (since we can already
detect th
On Sun, Nov 13, 2005 at 04:29:26AM -0500, Robert Dewar wrote:
> Richard Guenther wrote:
>
> >And this is why there seemed to be consensus to merge the two in the
> >middle-end and preserve debug-info somehow differently. Like with
> >a "frontend type-id" on the decl. That would allow lowering of
On Sunday 13 November 2005 08:23, Richard Kenner wrote:
> > A "function-never-returns-null" attribute doesn't seem like
> > the right mechanism. Instead, there should be a "never-null"
> > attribute on pointer types. A "function-never-returns-null" is
> > just a function whose ret
Richard Guenther wrote:
And this is why there seemed to be consensus to merge the two in the
middle-end and preserve debug-info somehow differently. Like with
a "frontend type-id" on the decl. That would allow lowering of f.i.
integral types to their modes at some point, too.
It seems a clea
On 13 Nov 2005 02:00:08 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | >
> | > Andrew Pinski <[EMAIL PROTECTED]> writes:
> | >
> | > | > | of what the semantics of REFERENCE_TYPE are/should be, then yes.
> | > | >
> | > | > See, it is not a sema
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | > | of what the semantics of REFERENCE_TYPE are/should be, then yes.
| > | >
| > | > See, it is not a semantics I made up. Even people arguing for null
| > | > reference recognize it is undefi
Paul Brook <[EMAIL PROTECTED]> writes:
| > | Well in fortran, all agruments are passed via a reference so that is just
| > | wrong. Using pointers there would be just wrong, as that is not the
| > | semantics for the variable.
| >
| > So, what is the semantics? What is the real difference?
|
|
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | > | of what the semantics of REFERENCE_TYPE are/should be, then yes.
> | >
> | > See, it is not a semantics I made up. Even people arguing for null
> | > reference recognize it is undefined behaviour.
> |
> | With C++ yes but not with Fortran
> | Well in fortran, all agruments are passed via a reference so that is just
> | wrong. Using pointers there would be just wrong, as that is not the
> | semantics for the variable.
>
> So, what is the semantics? What is the real difference?
Did you actually read the thread I referenced?
The sh
Andrew Pinski <[EMAIL PROTECTED]> writes:
| > | of what the semantics of REFERENCE_TYPE are/should be, then yes.
| >
| > See, it is not a semantics I made up. Even people arguing for null
| > reference recognize it is undefined behaviour.
|
| With C++ yes but not with Fortran where there are op
On Saturday 12 November 2005 16:11, Per Bothner wrote:
> I'm clearly not explaining myself ...
>
Well, it doesn't help that I'm not really good at language stuff, so don't
worry and thanks for putting up with the silly questions.
> However, ideally the compiler should realize that x actually has
> | of what the semantics of REFERENCE_TYPE are/should be, then yes.
>
> See, it is not a semantics I made up. Even people arguing for null
> reference recognize it is undefined behaviour.
With C++ yes but not with Fortran where there are optional arguments.
So What you are saying is that Fortr
Paul Brook <[EMAIL PROTECTED]> writes:
| On Saturday 12 November 2005 20:57, Gabriel Dos Reis wrote:
| > Paul Brook <[EMAIL PROTECTED]> writes:
| > | On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote:
| > | > Per Bothner <[EMAIL PROTECTED]> writes:
| > | > | A "function-never-returns-null
On Saturday 12 November 2005 20:57, Gabriel Dos Reis wrote:
> Paul Brook <[EMAIL PROTECTED]> writes:
> | On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote:
> | > Per Bothner <[EMAIL PROTECTED]> writes:
> | > | A "function-never-returns-null" attribute doesn't seem like
> | > | the right me
Andrew Pinski <[EMAIL PROTECTED]> writes:
| Was there an example of:
|
|
| int f(int &);
|
| int g(void)
| {
| int *a = 0;
| return f(*a);
| }
|
|
| Yes this would be undefined code but so what.
So it is NOT a compeling example that a reference can be null. You
have to try harder, Andre
Tom Tromey wrote:
"Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> A type attribute is much more useful. For example it allows:
Per> String x = shared ? "x" : new String("x");
Per> // The type of x [in a single-assignment-world] is non-null.
I think we will need extra code to recognize
Diego Novillo wrote:
From a user's perspective I see the obvious drawback that you've just
forced me to edit a potentially large number of source files just to add
the __attribute__((never_null)).
I'm clearly not explaining myself ...
Of course I'm not proposing that. My point was that my p
>
> Paul Brook <[EMAIL PROTECTED]> writes:
>
> | On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote:
> | > Per Bothner <[EMAIL PROTECTED]> writes:
> | > | A "function-never-returns-null" attribute doesn't seem like
> | > | the right mechanism. Instead, there should be a "never-null"
> |
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Saturday 12 November 2005 13:36, Gabriel Dos Reis wrote:
|
| > I'm not convinced. I believe Per's suggestion is far superior, and
| > more general and does cover pretty well the issue at hand. Plus,
| > a pointer-type-without-null is another spelli
Paul Brook <[EMAIL PROTECTED]> writes:
| On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote:
| > Per Bothner <[EMAIL PROTECTED]> writes:
| > | A "function-never-returns-null" attribute doesn't seem like
| > | the right mechanism. Instead, there should be a "never-null"
| > | attribute on
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Per Bothner <[EMAIL PROTECTED]> writes:
| >
| > | A "function-never-returns-null" attribute doesn't seem like
| > | the right mechanism. Instead, there should be a "never-null"
| > | attribute on pointer types. A "function-never-returns-null" i
On Saturday 12 November 2005 14:35, Per Bothner wrote:
> The internal SSA form might be something like:
>
> foo()
> {
> if (test)
> {
> int __attribute__((never_null)) *p_1 =
> this_never_returns_NULL(); < ... use p without modifying it ... > <--
> p_1 never NULL here. }
>
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> A type attribute is much more useful. For example it allows:
Per> String x = shared ? "x" : new String("x");
Per> // The type of x [in a single-assignment-world] is non-null.
I think we will need extra code to recognize that String refe
Diego Novillo wrote:
> int *this_never_returns_NULL (void) __attribute__
((never_returns_null));
>
> We would not want to pin the never-null attribute to 'int *':
Well, of course. That's why we're talking about a type *variant*.
To emphasise: this is a type variant *in the gcc internals* - i
On Saturday 12 November 2005 13:36, Gabriel Dos Reis wrote:
> I'm not convinced. I believe Per's suggestion is far superior, and
> more general and does cover pretty well the issue at hand. Plus,
> a pointer-type-without-null is another spelling for reference type.
>
I'm thinking of C here, wher
Per Bothner wrote:
A "function-never-returns-null" attribute doesn't seem like
the right mechanism. Instead, there should be a "never-null"
attribute on pointer types. A "function-never-returns-null" is
just a function whose return-type has the "never-null" attribute.
Gabriel Does Reis wrote
On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote:
> Per Bothner <[EMAIL PROTECTED]> writes:
> | A "function-never-returns-null" attribute doesn't seem like
> | the right mechanism. Instead, there should be a "never-null"
> | attribute on pointer types. A "function-never-returns-null" is
>
> Per Bothner <[EMAIL PROTECTED]> writes:
>
> | A "function-never-returns-null" attribute doesn't seem like
> | the right mechanism. Instead, there should be a "never-null"
> | attribute on pointer types. A "function-never-returns-null" is
> | just a function whose return-type has the "never-
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Saturday 12 November 2005 12:27, Per Bothner wrote:
|
| > I think you're missing the point. The proposal is for a "type variant"
| > - not that different from say "constant".
| >
| Ah, yes, sorry about that. Yes, that would be useful as well. How
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Saturday 12 November 2005 12:05, Per Bothner wrote:
| > A "function-never-returns-null" attribute doesn't seem like
| > the right mechanism. Instead, there should be a "never-null"
| > attribute on pointer types. A "function-never-returns-null" is
|
Per Bothner <[EMAIL PROTECTED]> writes:
| A "function-never-returns-null" attribute doesn't seem like
| the right mechanism. Instead, there should be a "never-null"
| attribute on pointer types. A "function-never-returns-null" is
| just a function whose return-type has the "never-null" attribute
On Saturday 12 November 2005 12:29, Andrew Haley wrote:
> Diego Novillo writes:
>
> > if (shared_1)
> >x_4 = "x"
> > else
> > {
> > x_5 = new String("x");
> > x_6 = ASSERT_EXPR
> > }
> > x_7 = PHI
> >
> > VRP already knows that "x" is non-NULL. The new function attribut
On Sat, 2005-11-12 at 12:30 -0500, Diego Novillo wrote:
> On Saturday 12 November 2005 12:24, Laurent GUERBY wrote:
> > Note that this correspond to the "not null" feature added to Ada 2006
> > in various places, including pointer type definitions:
> >
> >type Ptr is not null access Integer;
>
On Saturday 12 November 2005 12:27, Per Bothner wrote:
> I think you're missing the point. The proposal is for a "type variant"
> - not that different from say "constant".
>
Ah, yes, sorry about that. Yes, that would be useful as well. However,
that is an orthogonal issue to having non-NULL f
On Saturday 12 November 2005 12:24, Laurent GUERBY wrote:
> Note that this correspond to the "not null" feature added to Ada 2006
> in various places, including pointer type definitions:
>
>type Ptr is not null access Integer;
>
Ah, this is different and it would be very helpful. If it's a lan
Diego Novillo writes:
> On Saturday 12 November 2005 12:19, Andrew Haley wrote:
>
> > Couldn't we attach an assertion to the tree? That way we could just
> > use the inference logic we already have.
> >
> We already do that. In Per's test case,
>
> String x = shared ? "x" : new String(
Diego Novillo wrote:
On Saturday 12 November 2005 12:05, Per Bothner wrote:
A "function-never-returns-null" attribute doesn't seem like
the right mechanism. Instead, there should be a "never-null"
attribute on pointer types. A "function-never-returns-null" is
just a function whose return-type
On Saturday 12 November 2005 12:19, Andrew Haley wrote:
> Couldn't we attach an assertion to the tree? That way we could just
> use the inference logic we already have.
>
We already do that. In Per's test case,
String x = shared ? "x" : new String("x");
we get into VRP with an SSA form along
Note that this correspond to the "not null" feature added to Ada 2006
in various places, including pointer type definitions:
type Ptr is not null access Integer;
You can also have a regular pointer type and subtype it
with not null, but I guess the Ada front-end introduces
a generated subtype:
Diego Novillo writes:
> On Saturday 12 November 2005 12:05, Per Bothner wrote:
> > A "function-never-returns-null" attribute doesn't seem like
> > the right mechanism. Instead, there should be a "never-null"
> > attribute on pointer types. A "function-never-returns-null" is
> > just a functi
On Saturday 12 November 2005 12:05, Per Bothner wrote:
> A "function-never-returns-null" attribute doesn't seem like
> the right mechanism. Instead, there should be a "never-null"
> attribute on pointer types. A "function-never-returns-null" is
> just a function whose return-type has the "never-n
A "function-never-returns-null" attribute doesn't seem like
the right mechanism. Instead, there should be a "never-null"
attribute on pointer types. A "function-never-returns-null" is
just a function whose return-type has the "never-null" attribute.
A type attribute is much more useful. For ex
On Fri, 2005-11-11 at 22:53 -0800, Ian Lance Taylor wrote:
> David Daney <[EMAIL PROTECTED]> writes:
>
> > > Eventually we should manually mark certain function DECLs as
> > > not-returning-null instead of my kludgy test for this one case. I don't
> > > know if/when I can get to that. Perhaps so
On Saturday 12 November 2005 01:53, Ian Lance Taylor wrote:
> Note that it is also possible to simply store the attribute on
> DECL_ATTRIBUTES and look it up using lookup_attribute.
>
This is my strong preference. The original RFE (PR 20318) called for
attributes to be used in C/C++ function dec
David Daney <[EMAIL PROTECTED]> writes:
> > Eventually we should manually mark certain function DECLs as
> > not-returning-null instead of my kludgy test for this one case. I don't
> > know if/when I can get to that. Perhaps somebody else can take it from
> > here.
>
> Looks like all the bits i
Thanks Anthony. This has been bothering me for quite some time.
Anthony Green wrote:
Our compiler inlines many null pointer tests because the language
requires that we throw NullPointerExeceptions in certain cases that can
only be detected through explicit tests.
What's frustrating is that the
82 matches
Mail list logo
