In c programming language, a NULL pointer would point to a designate
memory location...
is this new or interessing ?!
best regards
andre
Greetings All,
I seem to have probably traced this bug down but am not sure what is the best
way
to fix it being new here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395#add_comment
Seems the issue is in va_heap::reserve in vec.h as we aren't checking if v is
equal to N like in vaheap::rel
On Mon, 20 Aug 2018, Richard Biener wrote:
P p+ N is nonnull if P or N is known to be nonnull
(and something similar for &p->field and others)
But we already do that.
Oups... I never noticed, I should have checked.
else if (code == POINTER_PLUS_EXPR)
{
/* For pointer t
On Mon, Aug 20, 2018 at 1:05 PM Marc Glisse wrote:
>
> On Mon, 20 Aug 2018, Richard Biener wrote:
>
> > On Mon, Aug 20, 2018 at 10:53 AM Andreas Schwab wrote:
> >>
> >> On Aug 20 2018, Richard Biener wrote:
> >>
> >>> Btw, I can't find wording in the standards that nullptr + 1 is
> >>> invoking
On Mon, 20 Aug 2018, Richard Biener wrote:
On Mon, Aug 20, 2018 at 10:53 AM Andreas Schwab wrote:
On Aug 20 2018, Richard Biener wrote:
Btw, I can't find wording in the standards that nullptr + 1 is
invoking undefined behavior,
that is, that pointer arithmetic is only allowed on pointers p
On Mon, Aug 20, 2018 at 10:53 AM Andreas Schwab wrote:
>
> On Aug 20 2018, Richard Biener wrote:
>
> > Btw, I can't find wording in the standards that nullptr + 1 is
> > invoking undefined behavior,
> > that is, that pointer arithmetic is only allowed on pointers pointing
> > to a valid object.
>
On Aug 20 2018, Richard Biener wrote:
> Btw, I can't find wording in the standards that nullptr + 1 is
> invoking undefined behavior,
> that is, that pointer arithmetic is only allowed on pointers pointing
> to a valid object.
> Any specific pointers?
All of 5.7 talks about pointers pointing to
On Mon, 20 Aug 2018 at 09:41, Jonathan Wakely wrote:
> C++17 has similar wording in 8.7 [expr.add] paragraph 4.
N.B. C++ adds a special case for adding the value 0 to null pointers,
so that it's well-defined (paragraph 7).
ly defines addition and subtraction for pointers
pointing to elements and past-the-end positions of arrays [1]. As a null
pointer ipoints to nothing, the 'otherwise' clauses apply, rendering the
behavior undefined.
The C++ standard has a couple of similar paragraphs [2]. In addition
only allowed on pointers pointing
> to a valid object.
> Any specific pointers?
C11 6.5.6 paragraph 8 says the result is only defined if the pointer
and the result of the addition point to elements of the same array
object, or one past the end of the array (where a non-array object is
treate
On Wed, Aug 15, 2018 at 7:44 AM Liu Hao wrote:
>
> 在 2018-08-15 12:48, Jeff Law 写道:
> > I just don't think anyone's ever bothered to catch this case. I believe
> > there is a BZ which touches on this issue.
> >
>
> Yes, here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
>
> This PR us
在 2018-08-15 12:48, Jeff Law 写道:
I just don't think anyone's ever bothered to catch this case. I believe
there is a BZ which touches on this issue.
Yes, here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
This PR uses a placement new as the example, which in GCC 8 assumes the
poi
On 08/14/2018 09:45 PM, Liu Hao wrote:
> Dear GCC people,
>
> At the moment, with GCC 8.2, I compile the program
>
> ```
> int foo(const char *p)
> {
> if(p == 0)
> return 2;
> const char *q = p + 1;
> if(q == 0)
> return 1;
> return 0;
> }
> ```
>
> using
>
> ``
Dear GCC people,
At the moment, with GCC 8.2, I compile the program
```
int foo(const char *p)
{
if(p == 0)
return 2;
const char *q = p + 1;
if(q == 0)
return 1;
return 0;
}
```
using
```
gcc-8 test.c -Wall -Wextra -Wpedantic -O3 -S
```
and get the following as
deep into looking at just what was visible
in the preprocessed code (c-common I think) and didn't look at
calculate_allocation from vec.c.
So this a false positive for my null pointer dereference checker.
There's nothing to propagate the fact that calculate_allocation can not
return
*&v, unsigned ix, const T &obj
> CXX_MEM_STAT_INFO)
> {
> vec_safe_reserve (v, 1, false PASS_MEM_STAT);
> v->quick_insert (ix, obj);
> }
>
>
> So vec_prefix::calculate_allocation returns NULL, then
> vec_safe_{push,insert} (and possibly others) ca
_MEM_STAT_INFO)
{
vec_safe_reserve (v, 1, false PASS_MEM_STAT);
v->quick_insert (ix, obj);
}
So vec_prefix::calculate_allocation returns NULL, then
vec_safe_{push,insert} (and possibly others) can dereference a NULL
pointer if I'm reading the code correctly.
Similarly, the vec_sa
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
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
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
// dereference: access to object
> > | // If a is null, then SEGFAULT
> > | *a = 0;
> >
> > Again, that may or may not happen.
>
> Some operating systems load a page of zeroes at address zero, so the
> dereference of a null pointer has no visible effect
fig. This is because some of
> Andrew> libgcj is written on C++, and the C++ compiler FE does not insert
> Andrew> checks for null pointer accesses.
>
> I prefer to think of these ports as degraded, not impossible.
Can we agree on "broken" ?
Andrew.
written on C++, and the C++ compiler FE does not insert
Andrew> checks for null pointer accesses.
I prefer to think of these ports as degraded, not impossible. You
won't get NPEs in all situations, due to how we wrote the CNI code.
(This could be fixed, of course, but motivation is low.) Well-
lve dereferencing 'this', an explicit
David> check for null must be made when it cannot be proven that 'this' is
David> not null.
Note that on ports where we rely on SEGV generation on a null pointer
dereference, we actually only emit these explicit checks for calls to
fin
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
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
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
d
just hard to pin
down where you're driving at.
| > It is *just* one form of undefined behaviour.
|
| Are you saying that this portion of the code *will*
| invoke undefined behavior even if the pointer "a"
| is valid?
I'm saying that if you call foo with a null pointer, you
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
the outer space.
| // dereference: access to object
| // If a is null, then SEGFAULT
| *a = 0;
Again, that may or may not happen.
I understand that specifically a SEGFAULT may not happen,
but according to the excerpt from the GCC info page above,
"The compiler assumes
>
> Again, that may or may not happen.
Some operating systems load a page of zeroes at address zero, so the
dereference of a null pointer has no visible effect; a different form
of undefined behavior. DYNIX/ptx did that by default, and I think
that HP-UX does it. I much prefer a segfault.
Janis
"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 elimi
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
|
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
module could intentionally
| > | (if ill-adviseadly) simply invoke the function:
| > then it gets what it deserves. Check out GCC manual for null-pointer
| > check.
|
| From info gcc:
|
| `-fdelete-null-pointer-checks'
| Use global dataflow analysis to identify and eliminat
"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
n it gets what it deserves. Check out GCC manual for null-pointer
check.
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 would have halte
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?
>>that a reference *should* never be null? Especially within
| >>the server code (the implementation of "int f(int& a)" in this case.)
| > There are several examples. One is converting from a derived class
| > to a base class when there is multiple inheritan
a;
| > | | if(b ==0)
| > | {
| > | a();
| > | }
| > | else
| > | {
| > | b();
| > | }
| > According to the standard, the compiler can assume that the test is
| > always false, therefore rewrite the if-else as an unconditional ca
"int f(int& a)" in this case.)
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.
Another is the "delete" operator. It must first check that
"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
}
According to the standard, the compiler can assume that the test is
always false, therefore rewrite the if-else as an unconditional call to
b(). GCC already does some null-pointer check deleting.
Wow. I'm sure there is sound reasoning for this ... but I can't
understand what that mi
"int f(int& a)" in this case.)
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 prog
the compiler can assume that the test is
always false, therefore rewrite the if-else as an unconditional call to
b(). GCC already does some null-pointer check deleting.
-- Gaby
f "int f(int& a)" in this case.)
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.
Another is the "delete" operator. It must first check that the
that a reference is always initialized to a null pointer).
If it did so, I can almost guarantee that some free software package
will be flagged (I recall writing such code myself 10+ years ago, before I
knew better), but it still might be a good thing.
Of course, it's not hard to hide the fa
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
it an error (since we can already
detect that a reference is always initialized to a null pointer).
If it did so, I can almost guarantee that some free software package
will be flagged (I recall writing such code myself 10+ years ago, before I
knew better), but it still might be a good thing.
Of cou
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
ent.
Right - the "type-variant" approach handles that smoothly.
I.e. in Java a string literal would have type
"never-null pointer to java.lang.String".
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
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(
say "constant".
"non-null java.lang.String" is a different POINTER_TYPE object than
"[possibly-null] java.lang.String". If you dereference an expression
whose type is "non-null java.lang.String" then you know you don't need
an null pointer check. If you de
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
99 matches
Mail list logo
