Re: Weird result of getsockopt

[CodeSun via Digitalmars-d-learn]

On Sunday, 24 May 2015 at 21:11:34 UTC, Daniel Kozak wrote:

On Sunday, 24 May 2015 at 16:51:44 UTC, CodeSun wrote:

Hello guys,
Today, I found a weird problem when I was learning to enable 
SO_KEEPALIVE for a specific socket. I use setsockopt to enable 
keepalive firstly, and then use getsockopt to show if it is 
enabled correctly.


My code snippet is listed below:

Dlang version:

import core.sys.posix.sys.socket;
import core.sys.posix.netinet.in_;
import std.c.stdio;

void main() {
int sfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
int flag = 1;
size_t size;
	setsockopt(sfd, SOL_SOCKET, SO_KEEPALIVE, &flag, 
cast(socklen_t)flag.sizeof);

flag = 0;
	getsockopt(sfd, SOL_SOCKET, SO_KEEPALIVE, &flag, 
cast(socklen_t*)&size);

printf("%d\n", flag);
}

C version:

#include 
#include 
#include 

int main() {
int sfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
int flag = 1;
size_t size;
	setsockopt(sfd, SOL_SOCKET, SO_KEEPALIVE, &flag, 
(socklen_t)sizeof(flag));

flag = 0;
	getsockopt(sfd, SOL_SOCKET, SO_KEEPALIVE, &flag, 
(socklen_t*)&size);

printf("%d\n", flag);
return 0;
}

Dlang version always prints 0, which means keepalive is not 
enabled, while C version can almost display 1  all the time as 
expected.


So is there anything wrong inside the code? If not, whose 
behavior is correct?


Cause your code is wrong:
"If the size of the option value is greater than option_len, 
the value stored in the object pointed to by the option_value
   argument shall be silently truncated. Otherwise, the 
object pointed to by the option_len argument shall be modified 
to indicate the  actual

   length of the value."

So because you have size set to 0 it will not work, you mast 
call it again and than it will probably work.


In C this work because size is not initialize which mean it 
could be anything


You are right, thx.

Weird result of getsockopt

[CodeSun via Digitalmars-d-learn]

Hello guys,
Today, I found a weird problem when I was learning to enable 
SO_KEEPALIVE for a specific socket. I use setsockopt to enable 
keepalive firstly, and then use getsockopt to show if it is 
enabled correctly.


My code snippet is listed below:

Dlang version:

import core.sys.posix.sys.socket;
import core.sys.posix.netinet.in_;
import std.c.stdio;

void main() {
int sfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
int flag = 1;
size_t size;
	setsockopt(sfd, SOL_SOCKET, SO_KEEPALIVE, &flag, 
cast(socklen_t)flag.sizeof);

flag = 0;
	getsockopt(sfd, SOL_SOCKET, SO_KEEPALIVE, &flag, 
cast(socklen_t*)&size);

printf("%d\n", flag);
}

C version:

#include 
#include 
#include 

int main() {
int sfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
int flag = 1;
size_t size;
	setsockopt(sfd, SOL_SOCKET, SO_KEEPALIVE, &flag, 
(socklen_t)sizeof(flag));

flag = 0;
	getsockopt(sfd, SOL_SOCKET, SO_KEEPALIVE, &flag, 
(socklen_t*)&size);

printf("%d\n", flag);
return 0;
}

Dlang version always prints 0, which means keepalive is not 
enabled, while C version can almost display 1  all the time as 
expected.


So is there anything wrong inside the code? If not, whose 
behavior is correct?

Weird link error

[CodeSun via Digitalmars-d-learn]

I have test a snippet of code, and I encountered with a weird 
link error.

The following is the demo:

import std.stdio;
interface Ti {
T get(T)(int num);
T get(T)(string str);
}

class Test : Ti {
T get(T)(int num) {
writeln("ok");
}
T get(T)(string str) {
writeln(str);
}
}
void main() {
Ti tt = new Test;
tt.get!string("test");
tt.get!string(123);
}


When I use dmd to compile this code snippet, the following link 
error was reported:
tt.d:(.text._Dmain+0x3b)：‘_D2tt2Ti12__T3getTAyaZ3getMFAyaZAya’ 
undefined reference
tt.d:(.text._Dmain+0x49)：‘_D2tt2Ti12__T3getTAyaZ3getMFiZAya’undefined 
reference


And if I modigy the code to
Test tt = new Test;

then this code will work.

So does it mean I can't declare function template inside 
interface? If so, why didn't dmd report the error while compiling 
instead of linking?


And where I can find the D symbol definition, because information 
like ‘_D2tt2Ti12__T3getTAyaZ3getMFAyaZAya’ makes me really 
confused.