2017-01-28 1 views

답변

0

문제는 약간로 공식화 될 수있다 :

밖으로 파일 기술자를 추출 핸들의

역설적으로 이것은 마이그레이션 가이드 t 섹션의 제목입니다. libuv 1.0 (자세한 내용은 here 참조). 그것은 다음과 같이 버전 1.0 전에

, 그렇게 할 수있는하지 않는 것이 좋습니다 방법은 라이브러리의 내부에 접근했다 : libuv v1.0을하기 때문에, 추천 방법은 대신 uv_fileno을 사용

handle->io_watcher.fd 

.

플랫폼 종속 파일 기술자와 동등한를 가져옵니다 :
문서는 상태.
TCP, 파이프, TTY, UDP 및 폴링과 같은 핸들이 지원됩니다. [...]

따라서 libuv의 버전에 따라 핸들에서 벗어나는 가장 좋은 방법입니다.

-1

클라이언트의 uv_fileno 기능을 클라이언트의 uv_stream에 사용할 수 있습니다.

리눅스와 다윈에

반환 uv_os_fd_tint에 대한 별칭입니다, 그래서 당신은 다음과 같은 작업을 수행 할 수

uv_tcp_t *client; 
int conn_s; 

// ... 

uv_accept(server, (uv_stream_t*) client); 
uv_fileno((uv_handle_t *)client, &conn_s); 
printf("%d", conn_s); 
+1

그건 잘못된 스타일이고'typedef'가'int'가 아닌 다른 것으로 변경되면 정의되지 않은 행동을합니다. 'uv_handle_t'를 사용하여 컴파일러를 변환시킵니다. 이렇게하면 컴파일러가 변환에 발생할 수있는 문제를보고 할 수 있습니다. – Olaf

+0

감사합니다. 답으로 쓸 수 있습니까? – Midiparse

+0

그러나 귀하의 우려를 이해하지 못합니다. 변환에 문제가있는 경우 컴파일러에서보고합니다. 'long conn_s;'로 바꾼다면, 경고 : 은 'long *'타입의 매개 변수에 '32 * '를 전달하는 호환되지 않는 포인터 타입을 나타냅니다 [-Wincompatible-pointer-types] uv_fileno ((uv_handle_t *) client, conn_s); ' – Midiparse

관련 문제