Jump to page: 1 26  
Page
Thread overview
prog segfaults
Jul 28, 2004
Ant
Jul 28, 2004
Derek Parnell
Jul 28, 2004
Ant
Jul 28, 2004
Andy Friesen
Jul 28, 2004
Ant
Jul 28, 2004
Walter
Jul 28, 2004
Derek Parnell
Jul 28, 2004
Regan Heath
Jul 28, 2004
Walter
Jul 28, 2004
Derek Parnell
Jul 28, 2004
Walter
Jul 28, 2004
Daniel Horn
Jul 28, 2004
Walter
[help] debuging on linux (was Re: prog segfaults)
Jul 28, 2004
Ant
Jul 28, 2004
Ben Hinkle
Jul 28, 2004
Ant
Jul 28, 2004
Ben Hinkle
Jul 29, 2004
Ant
Jul 28, 2004
Walter
Jul 28, 2004
Nick
Jul 28, 2004
Walter
Jul 28, 2004
Nick
Jul 28, 2004
Russ Lewis
Jul 29, 2004
Walter
Jul 28, 2004
Ant
Jul 28, 2004
Walter
Jul 28, 2004
Regan Heath
Jul 29, 2004
Walter
Jul 29, 2004
Regan Heath
Jul 29, 2004
Walter
Jul 29, 2004
Mickey Finn
Jul 29, 2004
Mickey Finn
Jul 29, 2004
Farmer
Jul 29, 2004
Sean Kelly
Jul 30, 2004
Russ Lewis
Jul 30, 2004
Regan Heath
Jul 30, 2004
Regan Heath
View/Copy Stack for Later Debug was: prog segfaults
Jul 30, 2004
Russ Lewis
Jul 30, 2004
Ant
Jul 30, 2004
parabolis
Jul 30, 2004
Russ Lewis
Jul 30, 2004
Regan Heath
Jul 30, 2004
parabolis
Jul 30, 2004
Russ Lewis
Jul 30, 2004
parabolis
Jul 30, 2004
Russ Lewis
Jul 30, 2004
parabolis
Jul 30, 2004
Russ Lewis
Jul 30, 2004
parabolis
Aug 01, 2004
Regan Heath
Aug 01, 2004
parabolis
Aug 01, 2004
Arcane Jill
Aug 01, 2004
parabolis
Jul 30, 2004
parabolis
Jul 30, 2004
Russ Lewis
Jul 30, 2004
parabolis
July 28, 2004
(for sure I'm overseeing something)

bug report (?) should I post on the bugs group?

I was trying to confirm we need to initialize objects pass with "out" and the executable for this just segfaults:

#############
class A
{
	int a;
}

void f(out A a)
{
	assert(a); // OK IF REPLACE BY assert(a!==null);
	printf("hello\n");
}

void main()
{
	A a = new A();
	f(a);
}
##############

Ant





















here is the 10 lines version:
class A{int a;}

void f(out A a)
{
	assert(a);
	printf("hello\n");
}

void main()
{A a = new A();f(a);}

July 28, 2004
On Tue, 27 Jul 2004 21:09:07 -0400, Ant wrote:

> class A
> {
> 	int a;
> }
> 
> void f(out A a)
> {
> 	assert(a); // OK IF REPLACE BY assert(a!==null);
> 	printf("hello\n");
> }
> 
> void main()
> {
> 	A a = new A();
> 	f(a);
> }

When function 'f' gets its parameters, the 'a' will be null because of the 'out' option. Even though you passed a new instance of A to it, the out option will initialize it to null. The assert is probably redundant as this is the expected behaviour of the language.

Try this code, it should crash with an access violation on the second
writef() call because the f() call's out option initialized it.

<code>
 import std.stdio;
 class A
 {
    int x;
 }

 void f(out A a)
 {
    assert(a is null);
    writef("hello\n");
 }

 void main()
 {
    A a = new A;
    a.x = 1;
    writef("before= %d\n", a.x);
    f(a);
    writef("after = %d\n", a.x);
 }
</code>

-- 
Derek
Melbourne, Australia
28/Jul/04 12:12:07 PM
July 28, 2004
On Wed, 28 Jul 2004 12:18:37 +1000, Derek Parnell wrote:

> On Tue, 27 Jul 2004 21:09:07 -0400, Ant wrote:
> 
>> class A
>> {
>> 	int a;
>> }
>> 
>> void f(out A a)
>> {
>> 	assert(a); // OK IF REPLACE BY assert(a!==null);
>> 	printf("hello\n");
>> }
>> 
>> void main()
>> {
>> 	A a = new A();
>> 	f(a);
>> }
> 
> When function 'f' gets its parameters, the 'a' will be null because of the 'out' option. Even though you passed a new instance of A to it, the out option will initialize it to null. The assert is probably redundant as this is the expected behaviour of the language.



yes, that's what I was trying to confirm.

but the program shouldn't segfault!
it should print and assertion failure. (?)

Ant


July 28, 2004
Ant wrote:
> On Wed, 28 Jul 2004 12:18:37 +1000, Derek Parnell wrote:
> 
>>>void f(out A a)
>>>{
>>>	assert(a); // OK IF REPLACE BY assert(a!==null);
>>>	printf("hello\n");
>>>}
>>>
>>When function 'f' gets its parameters, the 'a' will be null because of the
>>'out' option. Even though you passed a new instance of A to it, the out
>>option will initialize it to null. The assert is probably redundant as this
>>is the expected behaviour of the language. 
> 
> yes, that's what I was trying to confirm.
> 
> but the program shouldn't segfault!
> it should print and assertion failure. (?)

assert(a); is a special case in the language: it is not a boolean not-null test, it runs A's invariant to assert that 'a' is correct.

Still, you would think that an assertion failure would trip, since part of Object.invariant is "assert(this!==null);"

 -- andy
July 28, 2004
On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:

> 
> assert(a); is a special case in the language: it is not a boolean not-null test, it runs A's invariant to assert that 'a' is correct.

I didn't know that, cheking documentation ... checked, good!

> 
> Still, you would think that an assertion failure would trip, since part of Object.invariant is "assert(this!==null);"
> 

so looks like a bug, smells like a bug, is it a bug?

Ant

July 28, 2004
"Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.07.28.03.06.34.780054@yahoo.ca...
> On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:
>
> >
> > assert(a); is a special case in the language: it is not a boolean not-null test, it runs A's invariant to assert that 'a' is correct.
>
> I didn't know that, cheking documentation ... checked, good!
>
> >
> > Still, you would think that an assertion failure would trip, since part of Object.invariant is "assert(this!==null);"
> >
>
> so looks like a bug, smells like a bug, is it a bug?

No. assert(a) doesn't bother checking to see if a is null before calling the invariant, because the hardware will do that for you. Why duplicate what the hardware does?


July 28, 2004
On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:

> "Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.07.28.03.06.34.780054@yahoo.ca...
>> On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:
>>
>>>
>>> assert(a); is a special case in the language: it is not a boolean not-null test, it runs A's invariant to assert that 'a' is correct.
>>
>> I didn't know that, cheking documentation ... checked, good!
>>
>>>
>>> Still, you would think that an assertion failure would trip, since part of Object.invariant is "assert(this!==null);"
>>>
>>
>> so looks like a bug, smells like a bug, is it a bug?
> 
> No. assert(a) doesn't bother checking to see if a is null before calling the invariant, because the hardware will do that for you. Why duplicate what the hardware does?

Because assert() gives us filename and line number, but "Access Violation"
doesn't.

-- 
Derek
Melbourne, Australia
28/Jul/04 2:29:38 PM
July 28, 2004
On Wed, 28 Jul 2004 14:35:05 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:
>
>> "Ant" <duitoolkit@yahoo.ca> wrote in message
>> news:pan.2004.07.28.03.06.34.780054@yahoo.ca...
>>> On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:
>>>
>>>>
>>>> assert(a); is a special case in the language: it is not a boolean
>>>> not-null test, it runs A's invariant to assert that 'a' is correct.
>>>
>>> I didn't know that, cheking documentation ... checked, good!
>>>
>>>>
>>>> Still, you would think that an assertion failure would trip, since part
>>>> of Object.invariant is "assert(this!==null);"
>>>>
>>>
>>> so looks like a bug, smells like a bug, is it a bug?
>>
>> No. assert(a) doesn't bother checking to see if a is null before calling the
>> invariant, because the hardware will do that for you. Why duplicate what the
>> hardware does?
>
> Because assert() gives us filename and line number, but "Access Violation"
> doesn't.

Good point, in fact in debug mode I want all errors to give a file and line number, including access violation.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
July 28, 2004
"Derek Parnell" <derek@psych.ward> wrote in message news:ce7aei$2une$1@digitaldaemon.com...
> On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:
>
> > "Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.07.28.03.06.34.780054@yahoo.ca...
> >> On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:
> >>
> >>>
> >>> assert(a); is a special case in the language: it is not a boolean not-null test, it runs A's invariant to assert that 'a' is correct.
> >>
> >> I didn't know that, cheking documentation ... checked, good!
> >>
> >>>
> >>> Still, you would think that an assertion failure would trip, since
part
> >>> of Object.invariant is "assert(this!==null);"
> >>>
> >>
> >> so looks like a bug, smells like a bug, is it a bug?
> >
> > No. assert(a) doesn't bother checking to see if a is null before calling
the
> > invariant, because the hardware will do that for you. Why duplicate what
the
> > hardware does?
>
> Because assert() gives us filename and line number, but "Access Violation"
> doesn't.

Run it under the debugger, and the debugger will open up a window and put the cursor on it <g>.


July 28, 2004
On Tue, 27 Jul 2004 22:53:31 -0700, Walter wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:ce7aei$2une$1@digitaldaemon.com...
>> On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:
>>
>>> "Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.07.28.03.06.34.780054@yahoo.ca...
>>>> On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:
>>>>
>>>>>
>>>>> assert(a); is a special case in the language: it is not a boolean not-null test, it runs A's invariant to assert that 'a' is correct.
>>>>
>>>> I didn't know that, cheking documentation ... checked, good!
>>>>
>>>>>
>>>>> Still, you would think that an assertion failure would trip, since
> part
>>>>> of Object.invariant is "assert(this!==null);"
>>>>>
>>>>
>>>> so looks like a bug, smells like a bug, is it a bug?
>>>
>>> No. assert(a) doesn't bother checking to see if a is null before calling
> the
>>> invariant, because the hardware will do that for you. Why duplicate what
> the
>>> hardware does?
>>
>> Because assert() gives us filename and line number, but "Access Violation"
>> doesn't.
> 
> Run it under the debugger, and the debugger will open up a window and put the cursor on it <g>.

Sorry, too glib. Not impressed.

Why bother having assert give this info?

And which "the debugger" are you referring to?

-- 
Derek
Melbourne, Australia
28/Jul/04 4:40:23 PM
« First   ‹ Prev
1 2 3 4 5 6