Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 28, 2004 prog segfaults | ||||
---|---|---|---|---|
| ||||
(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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | 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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | 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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | 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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | "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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | "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 Re: prog segfaults | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
Copyright © 1999-2021 by the D Language Foundation