From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 477EA385737E for ; Wed, 20 Apr 2022 13:26:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 477EA385737E Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-320-R688cGwOPX-PVyubwXjmew-1; Wed, 20 Apr 2022 09:26:10 -0400 X-MC-Unique: R688cGwOPX-PVyubwXjmew-1 Received: by mail-wm1-f70.google.com with SMTP id p31-20020a05600c1d9f00b0038ed0964a90so963328wms.4 for ; Wed, 20 Apr 2022 06:26:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=giAFiUUDGGxV/51VvFZrobmsTCQrzjX+iXnYPu44i5o=; b=W4ejJ+2V7/xVIDr2LaPV0CeG/VWicPQpxHR9o47usTIXb5AOsBeTpVhWu0H5NCibc4 f5jYagWsyMUhJRS293f39phv4OqjqH4Yv4VWex5EtjYWjLkkSZ8Lscf8sbPdAXDfJbDc 3bud+MWlSyvuq6hsbMJIiOKnxLNSsgkwy3k+dsvfs11EUhhQR9h8DeWhqJq/sAhq/22a ikaRAa5K4npJ/xLwAzF6dU8nhbSpywWBE5BK80QLSipB5vJ2mO3YkLnUg7Qo0XFXXEnI nEDdYIRwCMmb5UQ8Qf431VlziIYFOc696ytjQ2UoDTkFtlIWf3GLltZAY6hT5buFmmL7 5DHg== X-Gm-Message-State: AOAM530dn0zZMJxsQJc4gq/ANacVWPzAf6Knw8a8ZuzhQGGaidUgD7HQ lixsOmZ2eqGre+6gyNHHwqWCEZcqtG/cDMViZLf/RH+BM7/Hj87CTz8Nl3XLbCmo9gi6aES5DO5 MsKflwv82c08NqCAxLUDVrQ== X-Received: by 2002:a1c:6a01:0:b0:37f:1b18:6b17 with SMTP id f1-20020a1c6a01000000b0037f1b186b17mr3711358wmc.146.1650461169707; Wed, 20 Apr 2022 06:26:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwLAXA/Gf9MWOFTOhkt/WjJDpT7hOt3JgS386MyeKkjbE31LcN6MUccglxiOCiVB71rw8boQ== X-Received: by 2002:a1c:6a01:0:b0:37f:1b18:6b17 with SMTP id f1-20020a1c6a01000000b0037f1b186b17mr3711344wmc.146.1650461169514; Wed, 20 Apr 2022 06:26:09 -0700 (PDT) Received: from localhost (host81-136-113-48.range81-136.btcentralplus.com. [81.136.113.48]) by smtp.gmail.com with ESMTPSA id c11-20020a05600c0a4b00b0037c91e085ddsm26639723wmq.40.2022.04.20.06.26.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 06:26:08 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii Cc: pedro@palves.net, brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: GDB 12.0.90 available for testing In-Reply-To: <838rs1ujzd.fsf@gnu.org> References: <87pmm096dc.fsf@redhat.com> <83zgl44w1m.fsf@gnu.org> <1379565857.1750775.1648990951974@mail.yahoo.com> <1113857996.1779276.1648999598328@mail.yahoo.com> <83czhyfa8i.fsf@gnu.org> <83wng1b161.fsf@gnu.org> <83tuaz6e3x.fsf@gnu.org> <874k2prr1c.fsf@redhat.com> <838rs1ujzd.fsf@gnu.org> Date: Wed, 20 Apr 2022 14:26:07 +0100 Message-ID: <87v8v3rimo.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2022 13:26:13 -0000 Eli Zaretskii via Gdb-patches writes: >> From: Andrew Burgess >> Cc: Eli Zaretskii , Joel Brobecker , pedro@palves.net >> Date: Tue, 19 Apr 2022 17:12:15 +0100 >> >> Sorry for the slow reply, I've been off for the last week, so I'm only >> just catching up with my GDB emails. >> >> How does the patch below look? This moves the setbuf call into a new >> function, and includes the comment from gdb_readline_no_editing_callback. > > Thanks. However, the patch that I tested only used the ISATTY test in > ui::ui, not in read_command. Not sure if that matters. I don't think it matters, the call in read_command_file will only be called with non-tty streams, in which case for MS-Windows we'll still make the setbuf call. If for some reason read_command_file does end up reading from a tty then my belief is we shouldn't be doing the setbuf call for MS-Windows (for the reasons discussed in this thread). Thanks, Andrew