From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eWA4K0yUfWrg5SIAWB0awg (envelope-from ) for ; Thu, 13 Aug 2026 05:54:20 -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=BppaqIi3; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AD4B51E033; Thu, 13 Aug 2026 05:54:20 -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 2D5951E033 for ; Thu, 13 Aug 2026 05:54:20 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 622BC4BA7990 for ; Thu, 13 Aug 2026 09:54:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 622BC4BA7990 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=BppaqIi3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 5F3044BA2E39 for ; Thu, 13 Aug 2026 09:53:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F3044BA2E39 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 5F3044BA2E39 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786614834; cv=none; b=qquysmLIxOYr5nK3sjposVnFdyBtWvVYqgWS4EpX1Vsjn6HY8Ne3vEI/XwWgYX8ZtQ2pa0HdHU0UQ5Yygr5CcSH8E1KssvoYSbIzZFP8DAei2dYCYO5X8Q6aD8GhZjJjDVZHhJ784fW/4Rvttv/nS3k8yIbotUuXhFuDtCIexow= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786614834; c=relaxed/simple; bh=OI3b0M/Aclhf5Ph1veLq4EauI8IUn3ckR6ZPORL+NfY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=BUV+3HrcSv1X/ecmhJbk5nGOB/l5NyU1uPpUZs97MF8A8oRYHQEPgR+Ks2n6+ZTr69lNnVYdiPWWwep5LfNzfIdQTZRiCY3ELCwL1BsRHF6591ybHZhZ3z0l0y7q0KRrN2d6r0lriYa5/K1Brm8qHbNg7QxUoOPcA86INGMgkWI= 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=BppaqIi3 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5F3044BA2E39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786614834; 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: in-reply-to:in-reply-to:references:references; bh=XLETgwDb+AfmtIp61/X1/XnOTjesVobjh62uzxMmVCI=; b=BppaqIi3tt6tz7riB1wIY3UkO40+Xr63wOCCSGyoDmf7ZL0ZoZJZMn2TjxEFfW4T4L+TW9 Lgdd829HCzCvp8RW9lziHTomR4m2V6dpVrOj34ipDZqtmxou0Zv2cNEnVqtUATWomBqOgt qHAtnmwknJtcuOSblAzYNKWMjTI4udw= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-530-I3a0DCfEP9-Ci_3pacG2fA-1; Thu, 13 Aug 2026 05:53:52 -0400 X-MC-Unique: I3a0DCfEP9-Ci_3pacG2fA-1 X-Mimecast-MFC-AGG-ID: I3a0DCfEP9-Ci_3pacG2fA_1786614831 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-47f6e8b5996so1808157f8f.2 for ; Thu, 13 Aug 2026 02:53:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786614831; x=1787219631; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=XLETgwDb+AfmtIp61/X1/XnOTjesVobjh62uzxMmVCI=; b=caT+WwTV7LuO24J2sf4s6nMAVBNSYsH3mgamK3m+yWzWdHeVcS4k6RaEbqHcAyDI0j 3wwBQWemt3HmVT1CXFjhykw4cxF6HIN0+5xAMv9YQbDCflQ8yHR5FRNfkSy32OulBbVm 9xEeDUGnf+IIXKcdxJlVuDENif2vTJwVUqWdWi79vYexGjqmHklTYTt2w2Jrfw+D5A5I dQG0nxzeS386FONwHrOv2AKaQKRI40EXyDpkwO9e319txaQD35vYQbBzw/2xMKnaW+Wc EAo9hNCUXGbsdBTsJ4YuBbxiG0ai95yl1fvC8Iy4yK8PT4wjTnglX/g+BgKJGY9u4TzX L35g== X-Gm-Message-State: AOJu0YyAdNjIw//DvTdEXgOx5hktHwcTxlfZ7fGTPYCzafKO3/0w1MTO Gg4KWvJv2k+nOK4Z0Xh5EjdI2k7zWBz5gQrub5K1bUTM2Hxkv1k14FpnvAnzIUVgVPjJVJRBe69 SLhNL4PsGmmCq57GOhRKLJWiWZJYSYTsH+1NaZ5FGC3FRYDlWMgnUw1QgvnHmvD0= X-Gm-Gg: AR+sD13u/BGY/ejBTHEVfM1r1mR4gfRtuMsh2J+3s+0KDaICnKcWyYSjd/k4BMhzG69 3ql6rdXPUkOGTqghSlUtYqSPY9kiSuxLJPqdhzcEoLAz1pvehOFO3AKIenGiorxCo3dmslKSxIi 8P9bjuDUWKNGSbjqRkbs3wAw52Q/a2P4KrVLqazOk9OVzU82l1VstLmoAd0auuxEDgjk+T8M60V GEa6lOuCsiX3ggEp8aCyrjKgP747wdfbgWP709xGWa4+8ZLqAl316bw1Fp1VnKILG+9Xxe2uIKb MNUQn0jdMcL/m4SMPP7J6Ew4wnAKF3Jz8e6Q7lfZA03FcHlDYJnZ9e5b++xSunCVfZI0F3zl5+e 8+c7Ok0wj1f0inkkY4zc= X-Received: by 2002:a05:6000:1889:b0:47f:762f:32a9 with SMTP id ffacd0b85a97d-48159cc2008mr6670501f8f.12.1786614830881; Thu, 13 Aug 2026 02:53:50 -0700 (PDT) X-Received: by 2002:a05:6000:1889:b0:47f:762f:32a9 with SMTP id ffacd0b85a97d-48159cc2008mr6670399f8f.12.1786614830211; Thu, 13 Aug 2026 02:53:50 -0700 (PDT) Received: from localhost (67.72.115.87.dyn.plus.net. [87.115.72.67]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815a568c40sm4929313f8f.13.2026.08.13.02.53.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 02:53:49 -0700 (PDT) From: Andrew Burgess To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv2] gdb/tui: use init_extended_color where possible In-Reply-To: <87qzk3w2d0.fsf@tromey.com> References: <5da7a3fea6997922a87508807efc3cadd119ff7c.1785930494.git.aburgess@redhat.com> <87qzk3w2d0.fsf@tromey.com> Date: Thu, 13 Aug 2026 10:53:48 +0100 Message-ID: <877blu1h3n.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: yjfS80itz7zdLOMZ9CmAscmnXBY19y4OfWFcl3pgQs8_1786614831 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Tom Tromey writes: >>>>>> "Andrew" == Andrew Burgess writes: > > Andrew> The motivation for using init_extended_color is slightly less than > Andrew> init_extended_pair. Assuming the terminal supports it the standard > Andrew> init_color API supports up to SHRT_MAX (32767) different colors, > Andrew> switching to init_extended_color removes the SHRT_MAX limit on color > Andrew> indices, allowing us to support the full range of COLORS. > > First, I think the patch is fine. > Approved-By: Tom Tromey > > However I have a question > > Andrew> /* We store RGB as 0..255, but curses wants 0..1000. */ > Andrew> - if (init_color (next, rgb[0] * 1000 / 255, rgb[1] * 1000 / 255, > Andrew> - rgb[2] * 1000 / 255) == ERR) > Andrew> + short r = rgb[0] * 1000 / 255; > Andrew> + short g = rgb[1] * 1000 / 255; > Andrew> + short b = rgb[2] * 1000 / 255; > Andrew> + > Andrew> + /* If init_extended_pair is not available then we fallback to > Andrew> + using init_pair. However, init_pair can only handle 'short' > Andrew> + color indices so there is no point using init_extended_color > Andrew> + to allow for the generation of longer 'int' color indices. */ > Andrew> +#if defined HAVE_INIT_EXTENDED_COLOR && defined HAVE_INIT_EXTENDED_PAIR > Andrew> + if (init_extended_color (next, r, g, b) == ERR) > Andrew> return false; > Andrew> +#else > Andrew> + /* NEXT is an int, but is passed as a short. If COLORS is > Andrew> + more than SHRT_MAX then NEXT will be truncated and end up > Andrew> + redefining a color entry that we don't expect. */ > Andrew> + if (next > SHRT_MAX > Andrew> + || init_color (next, r, g, b) == ERR) > Andrew> + return false; > Andrew> +#endif > > IIUC init_extended_color allows a bigger range for 'next' but also for > the RGB components. However despite the text above, I think we don't > actually use the bigger RGB range. And, perhaps we don't really care > to, I don't know. Great question! I also wondered about this as I too noticed that init_extended_color accepted r, g, b as `int`. The ncurses docs for this are super unclear, at least on my machine. For init_color I get an explicit paragraph which says: "Each of the last three arguments must be a value in the range 0 through 1000." But for init_extended_color my man page says: "Because color_content uses signed shorts for its parameters, that limits color-values and their red, green, and blue components to 32767 on modern hardware. The extension extended_color_content uses ints for the color value and for returning the red, green, and blue components, allowing a larger number of colors to be supported." which seems to suggest that r, g, b can have more range. However, note that even for init_color, where r, g, b are `short` the valid range is limited to 0 -> 1000, not the full short range as the text for init_extended_color seems to suggest. And the text for start_color, the general function to enable color support, has some text that talks about the range of the rgb components, and it too talks about 1000. None of this is super convincing. At least, none of it really convinced me. So in the end I just went to the sources. Looking at ncurses-6.6 source, in the file base/lib_color.c we see that both init_color and init_extended_color just forward their argument unmodified to _nc_init_color, which uses `int` for all its arguments, just like init_extended_color. After some initial checks, none of which check the rgb values, the code calls: if (InitColor && sp->_coloron && (color >= 0 && OkColorHi(color)) && (okRGB(r) && okRGB(g) && okRGB(b))) { /* This is where r, g, b are actually used. */ } And elsewhere in the file we find: #define okRGB(n) ((n) >= 0 && (n) <= 1000) Which for me is the definitive answer. The r, g, b components are always in the range 0 -> 1000 (inclusive). What this all means is that for both init_color and init_extended_color there are 1,000,000,000 different rgb color combinations that could be created, but init_color will only allow you to use 32,767 of these at a time, while init_extended_color will allow them all to be used. Is this super useful? Probably not. But it doesn't cost much to support it. Thanks, Andrew