zsh-workers
 help / color / mirror / code / Atom feed
From: "Jörg Sommer" <joerg@jo-so.de>
To: Oliver Kiddle <opk@zsh.org>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH 2/6] lex: Mark variables with const init as const
Date: Sat, 27 Jan 2024 07:41:20 +0100	[thread overview]
Message-ID: <4jkxcveoznwk7zps3wfnoxwo4wcjitwkfjzzynidj2p2zntwpk@uiydkr3zltjw> (raw)
In-Reply-To: <2942-1706254789.333425@NzBz.rL2-.PsQC>

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 269 bytes --]

  reply	other threads:[~2024-01-27  6:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-01 18:10 Extend usage of const char* Jörg Sommer
2024-01-01 18:10 ` [PATCH 1/6] zle.textobjects: Mark variables as const Jörg Sommer
2024-01-01 18:10   ` [PATCH 2/6] lex: Mark variables with const init " Jörg Sommer
2024-01-26  7:39     ` Oliver Kiddle
2024-01-27  6:41       ` Jörg Sommer [this message]
2024-01-28  0:18         ` Oliver Kiddle
2024-01-01 18:10   ` [PATCH 3/6] zle_vi: " Jörg Sommer
2024-01-01 18:10   ` [PATCH 4/6] zle_main: mark statusline " Jörg Sommer
2024-01-01 18:10   ` [PATCH 5/6] module: Mark name argument of some functions const Jörg Sommer
2024-01-01 18:10   ` [PATCH 6/6] zsh: mark hookdef.name as const Jörg Sommer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4jkxcveoznwk7zps3wfnoxwo4wcjitwkfjzzynidj2p2zntwpk@uiydkr3zltjw \
    --to=joerg@jo-so.de \
    --cc=opk@zsh.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).