From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50784 invoked by alias); 27 Sep 2019 14:53:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 50775 invoked by uid 89); 27 Sep 2019 14:53:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Sep 2019 14:53:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1569596022; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RHW8ArL33KPk0hXvwwUVJQ4XRA85GKLdlVs/W6fPM68=; b=brnfbdbyjT2P0Tlj65kojFvVH/UYMhi2Z5hT4mp5OdCc8mmXuU1QLvl6yzTza2JVubtywj oSqffwljJY+0bVRwEJMBVbHCqL+/oPu8Cxe5ROweTSPTuqkF8W+wASuaCWdHN1JcsnNbWd ndyMXVPqS1P3aUP3khfdnXAAVq3iQSE= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-106-f9_0dnfXMGyBMRCVCy7Epg-1; Fri, 27 Sep 2019 10:53:41 -0400 Received: by mail-wr1-f69.google.com with SMTP id i15so1146432wrx.12 for ; Fri, 27 Sep 2019 07:53:39 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id r28sm3802293wrr.94.2019.09.27.07.53.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Sep 2019 07:53:37 -0700 (PDT) Subject: Re: [RFC 00/17] Merge event loop implementations To: Eli Zaretskii References: <20190224165153.5062-1-tom@tromey.com> <3ae5ab8e-c219-6510-bb54-b30c1cf2d074@redhat.com> <87mueqslhn.fsf@tromey.com> <52b71425-e839-99fa-5045-8aaa02eafaef@redhat.com> <362e3e88-6e13-598c-6167-91076a6c478e@redhat.com> <8336ghkegs.fsf@gnu.org> Cc: tom@tromey.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <1a09dab3-9dc2-f864-00aa-5e3b3a0e2b13@redhat.com> Date: Fri, 27 Sep 2019 14:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <8336ghkegs.fsf@gnu.org> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-09/txt/msg00555.txt.bz2 On 9/27/19 3:20 PM, Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Fri, 27 Sep 2019 15:05:27 +0100 >> >> But, given that gdb (unlike gdbserver), has been using "int" >> for sockets on Windows for a long while, and 64-bit Windows >> has been a thing for a long while too, I wonder whether in >> practice Windows just makes sure that SOCKET handles >> fit in 32-bit integers, exactly to avoid porting headaches... >=20 > SOCKET is a 64-bit data type on 64-bit Windows. However, according to > this: >=20 > https://stackoverflow.com/questions/1953639/is-it-safe-to-cast-socket-t= o-int-under-win64 >=20 > Microsoft is unlikely to ever populate the high 32 bits with anything > but zero. >=20 > So I'd generally recommend using DWORDPTR or uintptr_t for SOCKETs, > but I'm guessing we are good using unsigned ints instead, if changing > that is too much trouble. Using unsigned ints would be as much trouble as any other type, because it'd be in conflict with the type that we want to use for Unix -- int. The main complication is that the code in question works with int file descriptors, and accepts / passes around all kinds of file descriptors, including PTYs, sockets, the console's file descriptor on Windows (fileno(stdin)), etc., all using a single type. So if we go the typedef way, it'd have to be a type that could fit all the different types of handles/descriptors on Windows (i.e., a 64-bit-wide unsigned integer in practice), and then all code that checks for handle validity would have to be tweaked to not do "fd < 0" or "fd =3D=3D -1" but instead maybe call some callback to validate the handle. That seems a lot of trouble, and unusual. The gnulib select route seems more attractive compared to that. Reading that stackoverflow, I'm convinced that we should just do what everyone does and cast SOCKET to int like gdb is already doing, and move on. Alternatively, if someone feels up to it, we could also borrow what gnulib's socket replacement does, which is to use these two macros to convert between a socket and a file descriptor: #define FD_TO_SOCKET(fd) ((SOCKET) _get_osfhandle ((fd))) #define SOCKET_TO_FD(fh) (_open_osfhandle ((intptr_t) (fh), O_RDWR | O_B= INARY)) _open_osfhandle "Associates a C run-time file descriptor with an existing o= perating system file handle.", per: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/open-osfh= andle?view=3Dvs-2019 But then again, might as well use gnulib's socket/select/etc. instead of redoing it ourselves. In conclusion, I suggest sweeping the issue under the rug for now and cast SOCKET to int for this series, like GDB already does. Actually, gdbserver also does that too -- gdb_socket_cloexec returns int, and gdbserver/remote-utils.c uses that to open sockets. So removing gdb_fildes_t is not really making things worse. Thanks, Pedro Alves