From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WWNqAx3JfGoEGyEAWB0awg (envelope-from ) for ; Wed, 12 Aug 2026 15:27:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1786562844; bh=HsGQdrOVXqdwExUHYPoqBb08avL7rJLa7qLON8Qog2o=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=w4n4CRCH/WdD3gW/eE0z+dl+liTyMXgd5IkrGLEcQdvygiuPrszEqtwdeJkZn2zte WBlLikOVhU25ZS1F34PHjfVbSd0Yzwm1p5EbxUzKKDQZmIT2O26fi23Od7fLwLqUzR Znhy3WerjrVqz+XWGtdRCkeTA1UoQjGu3Z4MhKSA= Received: by simark.ca (Postfix, from userid 112) id F16CC1E09B; Wed, 12 Aug 2026 15:27:24 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=OsEEo0vt; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 827F31E09B for ; Wed, 12 Aug 2026 15:27:24 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9EC9B4BB3B86 for ; Wed, 12 Aug 2026 19:27:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9EC9B4BB3B86 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=OsEEo0vt Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 524E84BA2E09 for ; Wed, 12 Aug 2026 19:27:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 524E84BA2E09 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 524E84BA2E09 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786562820; cv=none; b=xbc56MiGRVl6DaeTzbnJkVNddXxz/B2cTPoQNj2CD30GDxYG26dfo1T9cxwLB/xzmdYzZn70vBs8YwOck53dOkbIdmsBwPT4GgGlIeXLp9sKpOzkMyIO7rvyJ9/koCVSwFImBVbybJtZN3d66zlOlvKfS/BaEe8402wmDhpMRhE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786562820; c=relaxed/simple; bh=HsGQdrOVXqdwExUHYPoqBb08avL7rJLa7qLON8Qog2o=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=nAeYD/Hd5MwOPOXJHlBGjXCJUh9XVnfOZT/dMmknSuSvgSJFFecPpcAOIBJugpKtzYpKf0+3jsj82GUF2zVuUO0RBfxd8KAU7EujYaOyK3/PxFTidLSQX7kVF4F6EBmK3lI9dpb+26H1LQQLlvDVkR8ikf7lETnTq5F1Uv5tITs= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=OsEEo0vt DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 524E84BA2E09 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1786562819; bh=HsGQdrOVXqdwExUHYPoqBb08avL7rJLa7qLON8Qog2o=; h=Date:Subject:To:References:From:In-Reply-To:From; b=OsEEo0vtym3PAoB/6ksKqQhvv8G6PaOPJUAcZEZWJQeGW/EbCUlrV6XZbJxq0XC9i Tvsg8/QcT9azKDgSjC0JpNvRiN0K5XsyD9MFNM1NvzEAWPK0JVKDKhFriKGxqAh2ko a/49Jrg5+NZ/HWuCVKUtCMHzGnS01Am16xFSVefI= Received: by simark.ca (Postfix) id 08D091E09B; Wed, 12 Aug 2026 15:26:59 -0400 (EDT) Message-ID: Date: Wed, 12 Aug 2026 15:26:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv2] gdb/tui: use init_extended_color where possible To: Andrew Burgess , gdb-patches@sourceware.org References: <5da7a3fea6997922a87508807efc3cadd119ff7c.1785930494.git.aburgess@redhat.com> Content-Language: fr From: Simon Marchi In-Reply-To: <5da7a3fea6997922a87508807efc3cadd119ff7c.1785930494.git.aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 8/5/26 7:50 AM, Andrew Burgess wrote: > In v2: > > - Split the scaling of GDB's RGB value out from the init_color and > init_extended_color calls. This removes some code duplication and > allows the comment to sit closer to the code in question. > > - Rebase to current HEAD and retest. > > --- > > After commit: > > commit fbe7f20a0f098ca03913452b29f50f0dc8568f77 > Date: Sat May 9 23:27:43 2026 +0200 > > gdb/tui: fix unexpected reuse of color pairs > > which converted GDB to use init_extended_pair where possible, I > realised we could also make use of init_extended_color. > > The motivation for using init_extended_color is slightly less than > init_extended_pair. Assuming the terminal supports it the standard > init_color API supports up to SHRT_MAX (32767) different colors, > switching to init_extended_color removes the SHRT_MAX limit on color > indices, allowing us to support the full range of COLORS. > > But the cost of making this change is minimal, we already track the > color indices as an `int` within the global COLOR_MAP, so it's mostly > just a case of calling init_extended_color where needed. > > We only use init_extended_color when both that function and > init_extended_pair is available. The fallback to init_extended_pair > is init_pair, which expects the color indices to be shorts. If we are > using the init_pair fallback then using init_extended_color is > pointless. > > In reality init_extended_pair and init_extended_color were both added > in ncurses 6.1, so should both be available together. > > There is one additional change in here. Assuming that a terminal does > support more than SHRT_MAX colours, but for some reason GDB is > compiled with a version of the curses library that doesn't support > init_extended_color, then it is possible that in `get_color` the value > of NEXT could end up above SHRT_MAX, in which case the `init_color` > call will truncate the value of NEXT to a short and we will end up > redefining an earlier color index. To avoid this unlikely case I've > added a compare against SHRT_MAX. > > The init_extended_color path doesn't have this risk as COLORS is an > `int` and NEXT is passed as an `int` on this path so there is no risk > of truncation. Seems fine to me, thanks. Hopefully one day we can just assume that the extended functions are present. Approved-By: Simon Marchi Simon