Re: [PATCH 6/6] Use Arch instead of Debian for sr.ht builds

Alejandro Colomar via Mutt-dev <[email protected]> Tue, 24 Feb 2026 14:00:36 +0100
Newsgroups	gmane.mail.mutt.devel
Message-ID	<aZ2gXqAVz2MN3pGG@devuan>
On 2026-02-24T13:56:23+0100, Alejandro Colomar wrote:
> Hi Rene,
> 
> On 2026-02-24T13:41:26+0100, Rene Kita wrote:
> > This explains why it went so smooth with Arch. m-(
> > 
> > Running the build on Arch I get multiple errors of this kind:
> > browser.c:548:17: error: initialization discards 'const' qualifier from
> > pointer target type [-Werror=discarded-qualifiers]
> >   548 |       char *c = strrchr (d, '/');
> >       |                 ^~~~~~~
> > 
> > This is in function:
> > static int examine_directory (MUTTMENU *menu, struct browser_state *state,
> > 			      const char *d, const char *prefix).
> > 
> > AFAIU, strrchr is defined as: char * strrchr(const char *s, int c).
> 
> Being Arch, I suspect you're using the latest glibc.  C23 has changed
> the prototype of string search functions to use 'QChar', which is just
> a way of saying "the const qualifier, if present on the input, is
> preserved in the output".
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#subsubsection.7.26.5.6>
> 
> This makes it possible to write code that is more type-safe.
> 
> Since C23, the standard prototype for strrchr(3) is:
> 
> 	QChar *strrchr(QChar *s, int c);
> 
> which could be documented in a more C++-style way, with overloads:
> 
> 	char *strrchr(char *s, int c);
> 	const char *strrchr(const char *s, int c);
> 
> I now need to update the manual pages, and think I'm going to use the
> latter, although feel free to suggest some preference or some other way
> to document it.
> 
> The glibc commit that changed this was:
> 
> 	glibc.git cd748a63ab1a (2025-11-20; "Implement C23 const-preserving standard library macros")
> 
> which is contained in glibc-2.43.
> 
> > 
> > *c is changed later in that function, so we can't make it const. Any
> > ideas what's the best way forward from here?
> 
> If *c is later changed, and it derives from d, then d must be non-const,
> doesn't it?  Or is c later derived from another pointer?  If the latter
> is true, then we'd need to use a different local pointer variable.

After reading the source code myself, this looks like a bug.  d should
be non-const, as we modify it.

	$ grepc examine_directory . | grep -e '\<d\>' -e '\<c\>' -e { -e };
	./browser.c:static int examine_directory (MUTTMENU *menu, struct browser_state *state,
				      const char *d, const char *prefix)
	{
	  while (stat (d, &s) == -1)
	  {
	    {
	      char *c = strrchr (d, '/');
	      if (c && (c > d))
	      {
		*c = 0;
	      }
	    }
	    mutt_perror (d);
	  }
	  {
	    mutt_error (_("%s is not a directory."), d);
	  }
	  if ((dp = opendir (d)) == NULL)
	  {
	    mutt_perror (d);
	  }
	  {
	    mutt_buffer_concat_path (full_path, d, de->d_name);
	    {
	    }
	  }
	}

> 
> 
> Have a lovely day!
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>
signature.asc (application/pgp-signature, 833 B)