From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1789 invoked by alias); 27 Sep 2019 14:21:07 -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 1781 invoked by uid 89); 27 Sep 2019 14:21:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=sk:gdb-pat, sk:gdbpat, HX-Languages-Length:884 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Sep 2019 14:21:05 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iDr7H-00043e-I4; Fri, 27 Sep 2019 10:21:03 -0400 Received: from [176.228.60.248] (port=2116 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iDr7G-0006xA-Mb; Fri, 27 Sep 2019 10:21:03 -0400 Date: Fri, 27 Sep 2019 14:21:00 -0000 Message-Id: <8336ghkegs.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: tom@tromey.com, gdb-patches@sourceware.org In-reply-to: <362e3e88-6e13-598c-6167-91076a6c478e@redhat.com> (message from Pedro Alves on Fri, 27 Sep 2019 15:05:27 +0100) Subject: Re: [RFC 00/17] Merge event loop implementations 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00554.txt.bz2 > 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... SOCKET is a 64-bit data type on 64-bit Windows. However, according to this: https://stackoverflow.com/questions/1953639/is-it-safe-to-cast-socket-to-int-under-win64 Microsoft is unlikely to ever populate the high 32 bits with anything but zero. 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.