www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Some code that compiles but shouldn't

reply uranuz <neuranuz gmail.com> writes:
I have created library/ framework to handle JSON-RPC requests 
using D methods. I use some *template magic* to translate 
JSON-RPC parameters and return values from/ and to JSON. And I 
have encountered funny bug that at first was hard to find. My 
programme just segfaulted when call to this method occured:

	void getCompiledTemplate(HTTPContext ctx)
	{
		import std.exception: enforce;
		enforce(ctx, `ctx is null`);
		enforce(ctx.request, `ctx.request is null`);
		enforce(ctx.request.form, `ctx.request is null`);
		enforce(ivyEngine !is null, `ivyEngine is null`);
		string moduleName = ctx.request.form[`moduleName`];
		auto mod = ivyEngine.getByModuleName(moduleName);
		return ctx.response.write(mod.toStdJSON().toString());
	}


So as you see I have added a lot of enforce to test if all 
variables are not null. But nothing was null and the reason of 
segfault were unclear.
Today I just went home. Opened a bottle of beer. And have noticed 
that function is marked as returning `void`, but in fact it 
doesn't. When I fixed this segfault have gone. But why this even 
compiled?! Interesting...
Dec 30 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 30, 2019 at 06:18:49PM +0000, uranuz via Digitalmars-d-learn wrote:
[...]
 	void getCompiledTemplate(HTTPContext ctx)
 	{
 		import std.exception: enforce;
 		enforce(ctx, `ctx is null`);
 		enforce(ctx.request, `ctx.request is null`);
 		enforce(ctx.request.form, `ctx.request is null`);
 		enforce(ivyEngine !is null, `ivyEngine is null`);
 		string moduleName = ctx.request.form[`moduleName`];
 		auto mod = ivyEngine.getByModuleName(moduleName);
 		return ctx.response.write(mod.toStdJSON().toString());
 	}
 
 
 So as you see I have added a lot of enforce to test if all variables
 are not null. But nothing was null and the reason of segfault were
 unclear.  Today I just went home. Opened a bottle of beer. And have
 noticed that function is marked as returning `void`, but in fact it
 doesn't. When I fixed this segfault have gone. But why this even
 compiled?! Interesting...
That's weird indeed. Do you have a minimal case that reproduces this problem? I tried to return the result of a non-void function call from a void function, and it wouldn't compile, as expected. It would be interesting to see when exactly this compiler check is wrongly skipped. T -- Ignorance is bliss... until you suffer the consequences!
Dec 30 2019
prev sibling next sibling parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Monday, 30 December 2019 at 18:18:49 UTC, uranuz wrote:
 So as you see I have added a lot of enforce to test if all 
 variables are not null. But nothing was null and the reason of 
 segfault were unclear.
What about moduleName, mod and the return value of mod.toStdJSON()? And whats the return type of ctx.response.write? (Returning a void expression is allowed and avoids some special casing in generic code)
Dec 30 2019
next sibling parent uranuz <neuranuz gmail.com> writes:
On Monday, 30 December 2019 at 19:09:13 UTC, MoonlightSentinel 
wrote:
 On Monday, 30 December 2019 at 18:18:49 UTC, uranuz wrote:
 So as you see I have added a lot of enforce to test if all 
 variables are not null. But nothing was null and the reason of 
 segfault were unclear.
What about moduleName, mod and the return value of mod.toStdJSON()? And whats the return type of ctx.response.write? (Returning a void expression is allowed and avoids some special casing in generic code)
I have reviewed this code and ctx.response.write(...) returns void too.. ;-) So I don't even know if this is correct or no? Could I use `return void;`?
Dec 30 2019
prev sibling parent uranuz <neuranuz gmail.com> writes:
On Monday, 30 December 2019 at 19:09:13 UTC, MoonlightSentinel 
wrote:
 On Monday, 30 December 2019 at 18:18:49 UTC, uranuz wrote:
 So as you see I have added a lot of enforce to test if all 
 variables are not null. But nothing was null and the reason of 
 segfault were unclear.
What about moduleName, mod and the return value of mod.toStdJSON()? And whats the return type of ctx.response.write? (Returning a void expression is allowed and avoids some special casing in generic code)
OK. This example compiles... void bar() {} void main() { return bar(); }
Dec 30 2019
prev sibling parent Heromyth <bitworld qq.com> writes:
On Monday, 30 December 2019 at 18:18:49 UTC, uranuz wrote:
 I have created library/ framework to handle JSON-RPC requests 
 using D methods. I use some *template magic* to translate 
 JSON-RPC parameters and return values from/ and to JSON. And I 
 have encountered funny bug that at first was hard to find. My 
 programme just segfaulted when call to this method occured:

 	void getCompiledTemplate(HTTPContext ctx)
 	{
 		import std.exception: enforce;
 		enforce(ctx, `ctx is null`);
 		enforce(ctx.request, `ctx.request is null`);
 		enforce(ctx.request.form, `ctx.request is null`);
 		enforce(ivyEngine !is null, `ivyEngine is null`);
 		string moduleName = ctx.request.form[`moduleName`];
 		auto mod = ivyEngine.getByModuleName(moduleName);
 		return ctx.response.write(mod.toStdJSON().toString());
 	}


 So as you see I have added a lot of enforce to test if all 
 variables are not null. But nothing was null and the reason of 
 segfault were unclear.
 Today I just went home. Opened a bottle of beer. And have 
 noticed that function is marked as returning `void`, but in 
 fact it doesn't. When I fixed this segfault have gone. But why 
 this even compiled?! Interesting...
We also have a piece of code, see here https://github.com/huntlabs/hunt-examples/blob/master/website-basic/source/app/controller/IndexController.d#L133. It's a wrong function declaration. There is no error message when compiling it. However, the showString() can't be called via the browser, because the router mapping fails. What happened for this is that the IndexController is not used directly by others. It's used in `mixin MakeController;`, see https://github.com/huntlabs/hunt-framework/blob/master/source/hunt/framework/application/Controller.d#L153. So the conclusion is the mixin needs to do more works to check the validation in mixined code.
Dec 30 2019