Am Dienstag, dem 01.09.2026 um 15:11 +0000 schrieb Joseph Myers:
> On Tue, 1 Sep 2026, Martin Uecker wrote:
>
> > c: split -Wwrite-strings into a proper warning and a flag [PR61579]
> >
> > This adds a new flag -fconst-string-literals that toggles whether
> > string literals are const-qualified or not. The warning -Wwrite-strings
> > is reimplemented as warning that warns whenever a string literal is
> > implicitely converted to a pointer to a non-const-qualified character
> > type independently on whether the string literal is actually const
> > qualified or not. For C++ and with -fconst-string-literals also C,
> > the warning is activated by default.
>
> I think -Wwrite-strings has been around for so long with its current
> semantics that it should be considered a semantic option that changes the
> type of string literals, despite its -W name; anything that does not
> change the type should be named differently. (This does not prevent
> giving more precise diagnostics with -Wwrite-strings in the specific case
> of string literals, as long as they are consistent with still having
> const-qualified types - for example, as long as they remain pedwarns and
> typeof produces the const-qualified types.)
How about doing it the other way around: Instead of
-fconst-string-literals turning on -Wwrite-strings we
have -Wwrite-strings turn on -fconst-string-literals? Then the
behavior with just -Wwrite-strings remains the same as it always
was, but one can independently toggle it using
-fconst-string-literals (which then overwrites the default)?
Or do you prefer a new warning option?
>
> > +/* Test whether EXPR is a string literal. */
> > +
> > +static bool
> > +string_literal_p (tree expr)
>
> I suppose it's hard to get a c_expr, or information obtained from a
> c_expr, in the places where this information is needed? Since checking
> original_code against STRING_CST would seem cleaner than trying to
> reconstruct the information later.
I was thinking the same. It is on my TODO list to see whether
the use of c_expr can be extended more, but so far it seems it
would be a much larger change.
Martin
>
> > + expr = TREE_OPERAND(expr, 0);
>
> Missing space before '('.
>
> > @@ -8841,6 +8892,7 @@ convert_for_assignment (location_t location,
> > location_t expr_loc, tree type,
> > /* Opaque pointers are treated like void pointers. */
> > is_opaque_pointer = vector_targets_convertible_p (ttl, ttr);
> >
> > +
> > /* The Plan 9 compiler permits a pointer to a struct to be
> > automatically converted into a pointer to an anonymous field
> > within the struct. */
>
> Why the extra blank line?
>
> > @@ -9038,7 +9090,7 @@ convert_for_assignment (location_t location,
> > location_t expr_loc, tree type,
> > and vice versa; otherwise, targets must be the same.
> > Meanwhile, the lhs target must have all the qualifiers of the rhs. */
> > if ((VOID_TYPE_P (ttl) && !TYPE_ATOMIC (ttl))
> > - || (VOID_TYPE_P (ttr) && !TYPE_ATOMIC (ttr))
> > + || (VOID_TYPE_P (ttr) && !TYPE_ATOMIC (ttr)) // FIXME
>
> A FIXME isn't helpful without saying what's wrong that needs to be fixed.
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
