Oliver Kiddle schrieb am Fr 26. Jan, 08:39 (+0100):
> On 1 Jan, Jörg Sommer wrote:
> > Because these variables are initialized with as constant string, they should
> > be marked as *const* to make the compiler running with `-Wwrite-strings`
> > more happy.
> 
> Applying this patch series causes a couple of fresh warnings:
> 
> zle_thingy.c: In function 'bin_zle_refresh':
> zle_thingy.c:420:15: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>   420 |     char *s = statusline;
>       |
> 
> lex.c: In function 'exalias':
> lex.c:1964:20: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>  1964 |         zshlextext = tokstrings[tok];
>       |
> 
> clang describes these as "initializing 'char *' with an expression of
> type 'const char *' discards qualifiers
> [-Wincompatible-pointer-types-discards-qualifiers]".

Yes, it's a kind of chicken egg problem. Either it gets a really big patch
or you have steps that introduce new warnings and solve them with later
patches. I don't know what you prefer for review.

> I have no objection to adding const in more places where possible. You may
> find we have code that is not really modifying its parameter but relies on
> being able to temporarily swap a nul in for a character as part of
> parsing.

Unfortunately, in the sense of *const* this is a modification. And I think I
saw a function that expects to have modifiable memory, if it contains a
separator character. If it not, because its not user input and hence
pre-splitted, it doesn't modify the memory (and is const). Sorry, I don't
remember the name after that time.


My main question is how this patch set should be organized? One commit per
file which reduces the number of warnings in this file to the cost of new
warnings in other files?


Regards Jörg

-- 
Wenn du nur einen Hammer hast, sieht jedes Problem aus wie ein Nagel.