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...

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!

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)

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;`?

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();
}

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.