From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EyIBF8gjc2qfkAkAWB0awg (envelope-from ) for ; Wed, 05 Aug 2026 07:51:36 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gmV9NHaM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 361891E166; Wed, 05 Aug 2026 07:51:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 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 7EE201E09B for ; Wed, 05 Aug 2026 07:51:35 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 975764BAE7D2 for ; Wed, 5 Aug 2026 11:51:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 975764BAE7D2 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gmV9NHaM Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 992DB4B99F51 for ; Wed, 5 Aug 2026 11:50:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 992DB4B99F51 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 992DB4B99F51 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785930659; cv=none; b=CFVsIX1jXVzTmxcyBbZsueVsCkV6V3ATVB7G84SKZsHQXvmE8COxRRrN7GF4UwzN3jT0fbkzuX010n/5CEZ6EjoPBgD4vDPq23Jn71/nOT1w/FPFHiEzSuZ/B3+9zP3RJD7O73Xjhz5CQiwFhok3W82Ox6gEj+7qdDzY4uCbn/s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785930659; c=relaxed/simple; bh=G/6gCQEjSUzTUtXWW+zL2pHkMK0hl7VtyIoYGoImH9Y=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=myycSq4ImfXOYKgtTY2Cl+Gfqog2M3QkHei8Gkj0+fAdeyu3r1tKrd9uIfK7/7q1EUGoZKcs0jPV3M/mbZtXOGZUYhcQNj2HcUaVDCSydxQywKGFjsBtloBmwZ4sYVsuknn8vmOAojEDyJLAIzQ8hIkonBlboeW8wYI9iAo2TSY= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gmV9NHaM DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 992DB4B99F51 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785930659; 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=vTk2SSagmYEvvasRZD68vujle5SRzFpyp2P9sQzYS6k=; b=gmV9NHaMZFRE/b9/sL2gVmuBvqvJkUSa1OcPGg4K0MF1y1jHbT1Jlvfv9z/12ayUDrTnHR qHZjn2S+jyV4GnpwnH3VdV43s84gjqA/746e5kZ9Ya6TuXCAeg29DoOBWgxD7JhJhsZ6wW xEhNTyQVbGrYIYFK5RYHsSp57DDHeh8= 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.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-203-26ju-7xtMeqJXn--3Q-iAQ-1; Wed, 05 Aug 2026 07:50:58 -0400 X-MC-Unique: 26ju-7xtMeqJXn--3Q-iAQ-1 X-Mimecast-MFC-AGG-ID: 26ju-7xtMeqJXn--3Q-iAQ_1785930657 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4955b84e25eso5443965e9.1 for ; Wed, 05 Aug 2026 04:50:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785930657; x=1786535457; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=vTk2SSagmYEvvasRZD68vujle5SRzFpyp2P9sQzYS6k=; b=KYRFfRFXop6cIDTyaM6NF+l8qT7P6+sMHPB18zhkqoBxb+CF0glvcFmf1gP2+/lqSv ZXMp/sHfiTLKHb8d51QhHY5k3K6y3VysPBHRUruJGMOITej/Nf2HBZc3v/mqzbFcbRmr bN6vPcQvM6Nl1iB6nTQ9uPDs8lEml8+5ByRZ25ZNOHBD0oyt9fJFQP5kYHvn2/8SpYc/ ENUgxHZksU6FZ/1zCKh+lqX0rW7qn/Uf7VgNElnmPlRMPsg/6Z2ptkYMjw1VIySaXhSg TQdFoA38dPvrYTDtIJoxZF6Ba3WCzthY3Ic2PfMbWZxmuBKPiA1eWZpeJaKPvziSe3MR vqzw== X-Gm-Message-State: AOJu0YxCagzGP9e6Lr4lIVIQ9m8TQ1Xk+bdsscnarVdKc1h98ocVCcvp b04lWh+lLzoPuSqc5YcsqNJHhtJaRoTGx2LyXZEbw5cZ0R8ERGTIJ3glZKR05Ma54zWPrOJG3RG aEeWc+8DjibVcqgNXldxvFkvUYgtJXd6IVM/9W3YJXI9BIprnFnTLwEGhs9KraiefskqZzzsE3U IarHhGUu9evh+del2vr9Iho/3WuD0kWauzi2ZZihmi4WI9IFA= X-Gm-Gg: AR+sD13wuUBfqIJcSY4Cbq7cYfjL7ryPOunE6ToJENRdLoFRgywAJZET8CPjHk5BPco DbpQir0/lOQTE9xKZq0pzR9dhO+QWW9nT/FVSwuKW/GYaY6lQQllfhIbfdlA4LHb1i61FMYhmrz bcG1++fBiEWkV+Wp7omo+XmIrgP/kSYD/199KVbaJXefOYGEALNRw4nSHveJQC9CEZapQ9IQn19 2PB+Kksd2VqG5+VbU9+lb5oay07tMCKFTrmaQ46gglyRhDRCMzaxCz0792tJDWPTcbs9UZwC3aG EzhJ2hbl+HtbtpXluFETTmZ9bjvgsieQPn4bG7IAkK/ZPh/phggR5bHeS9yRibTIqINbNVLJmmg pCQzsOzi0n/RnqlNNi8ZXtVXl X-Received: by 2002:a05:600c:529b:b0:493:a613:56b2 with SMTP id 5b1f17b1804b1-4994e71d3e5mr81812505e9.8.1785930656876; Wed, 05 Aug 2026 04:50:56 -0700 (PDT) X-Received: by 2002:a05:600c:529b:b0:493:a613:56b2 with SMTP id 5b1f17b1804b1-4994e71d3e5mr81811285e9.8.1785930656079; Wed, 05 Aug 2026 04:50:56 -0700 (PDT) Received: from localhost (227.114.208.46.dyn.plus.net. [46.208.114.227]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4994a0f7bf4sm175704905e9.11.2026.08.05.04.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 04:50:55 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv2] gdb/tui: use init_extended_color where possible Date: Wed, 5 Aug 2026 12:50:53 +0100 Message-Id: <5da7a3fea6997922a87508807efc3cadd119ff7c.1785930494.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: zW78y3-VYAeoLUHLsQ_jpB-dbEOAp6E5aUjFjDflFV4_1785930657 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true 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 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. --- gdb/config.in | 3 +++ gdb/configure | 1 + gdb/configure.ac | 1 + gdb/tui/tui-io.c | 21 +++++++++++++++++++-- 4 files changed, 24 insertions(+), 2 deletions(-) diff --git a/gdb/config.in b/gdb/config.in index 1ef5dc5c2f4..74745665d4d 100644 --- a/gdb/config.in +++ b/gdb/config.in @@ -250,6 +250,9 @@ /* Define to 1 if you have the `iconvlist' function. */ #undef HAVE_ICONVLIST +/* Define to 1 if you have the `init_extended_color' function. */ +#undef HAVE_INIT_EXTENDED_COLOR + /* Define to 1 if you have the `init_extended_pair' function. */ #undef HAVE_INIT_EXTENDED_PAIR diff --git a/gdb/configure b/gdb/configure index 303d6ea011c..fe58ba47e73 100755 --- a/gdb/configure +++ b/gdb/configure @@ -30238,6 +30238,7 @@ for ac_func in \ getrlimit \ getuid \ iconvlist \ + init_extended_color \ init_extended_pair \ libiconvlist \ posix_madvise \ diff --git a/gdb/configure.ac b/gdb/configure.ac index e55a733fba7..3d8847df9d8 100644 --- a/gdb/configure.ac +++ b/gdb/configure.ac @@ -1520,6 +1520,7 @@ AC_CHECK_FUNCS([ \ getrlimit \ getuid \ iconvlist \ + init_extended_color \ init_extended_pair \ libiconvlist \ posix_madvise \ diff --git a/gdb/tui/tui-io.c b/gdb/tui/tui-io.c index 896d00f44c8..b6afe08be3e 100644 --- a/gdb/tui/tui-io.c +++ b/gdb/tui/tui-io.c @@ -252,10 +252,27 @@ get_color (const ui_file_style::color &color, int *result) if (next >= COLORS) return false; rgb_color rgb = color.get_rgb (); + /* We store RGB as 0..255, but curses wants 0..1000. */ - if (init_color (next, rgb[0] * 1000 / 255, rgb[1] * 1000 / 255, - rgb[2] * 1000 / 255) == ERR) + short r = rgb[0] * 1000 / 255; + short g = rgb[1] * 1000 / 255; + short b = rgb[2] * 1000 / 255; + + /* If init_extended_pair is not available then we fallback to + using init_pair. However, init_pair can only handle 'short' + color indices so there is no point using init_extended_color + to allow for the generation of longer 'int' color indices. */ +#if defined HAVE_INIT_EXTENDED_COLOR && defined HAVE_INIT_EXTENDED_PAIR + if (init_extended_color (next, r, g, b) == ERR) return false; +#else + /* NEXT is an int, but is passed as a short. If COLORS is + more than SHRT_MAX then NEXT will be truncated and end up + redefining a color entry that we don't expect. */ + if (next > SHRT_MAX + || init_color (next, r, g, b) == ERR) + return false; +#endif color_map[color] = next; *result = next; } base-commit: cd4e3876afb11e07fb7f3ccc10a87e3b990074eb -- 2.25.4