linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Kars Mulder' <kerneldev@karsmulder.nl>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kai-Heng Feng <kai.heng.feng@canonical.com>
Subject: RE: Writing to a const pointer: is this  supposed to happen?
Date: Sat, 27 Jun 2020 10:24:07 +0000	[thread overview]
Message-ID: <0ceda3b41fe446e792fce5ff2634c48f@AcuMS.aculab.com> (raw)
In-Reply-To: <1da2-5ef37080-31-6d4cde00@228034409>

From: Kars Mulder
> Sent: 24 June 2020 16:26
> On Wednesday, June 24, 2020 15:10 CEST, Greg Kroah-Hartman wrote:
> > Have you hit any runtime issues with this code doing this?  These
> > strings should be held in writable memory, right?  Or do you see a
> > codepath where that is not the case?
> 
> I haven't ran into any issues with it; I was just looking at the code
> as reference for a patch I'm working on.
> 
> I initially assumed that casting a const pointer to non-const and
> writing to it would be undefined behaviour, but after reading through
> the C99 standard I can't find an unambiguous statement whether it is
> undefined behaviour even if the const pointer points to an object that
> was originally non-const (like char* -> const char* -> char* casts); it
> only says it is undefined behaviour if the object was defined with the
> const qualifier.
> 
> I should probably stop bothering you with my newbie questions.

IISC The C standard 'rules' about casts only really allow a pointer to
be temporarily cast to a different type and then cast back to the
original type before being used.

One effect of that is code like:
void foo(bah_t *bahp)
{
	bah_t bah;
	/* Copy because bahp might be misaligned */
	memcpy(&bah, (void *)bahp, sizeof bah);
doesn't work because the compiler knows that 'bahp' must
point to aligned memory - because that is the only place
it can legitimately come from.
No amount of casts will stop it inlining memcpy() and using
wide register copier.

The code quoted (using strset()) is almost certainly wrong.
The caller is unlikely to expect the input be modified.
Since it doesn't fault the string must be in read-write memory.

Code can be compiled with -Wcast-qual that will generate a
warning when 'const' gets cast away.
There are some legitimate reasons to remove 'const', but not
many.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2020-06-27 10:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22 11:35 Writing to a const pointer: is this supposed to happen? Kars Mulder
2020-06-23 19:55 ` Pavel Machek
2020-06-24 12:34   ` Kars Mulder
2020-06-24 13:10     ` Greg Kroah-Hartman
2020-06-24 15:25       ` Kars Mulder
2020-06-27 10:24         ` David Laight [this message]
2020-07-01 23:03           ` Kars Mulder
2020-07-02  7:55             ` David Laight
2020-07-02 21:48               ` Kars Mulder
2020-07-03  8:13                 ` David Laight
2020-07-03 13:23                   ` Kars Mulder
2020-07-04 11:55                     ` Pavel Machek
2020-07-05 21:53                       ` [PATCH] usb: core: fix quirks_param_set() writing to a const pointer Kars Mulder
2020-07-06 10:34                         ` Greg Kroah-Hartman
2020-07-06 12:57                           ` Kars Mulder
2020-07-06 13:07                             ` Greg Kroah-Hartman
2020-07-06 13:58                               ` Kars Mulder
     [not found] <CAHp75Ve4O+OmVttjhtKepFWwZLU6tFMx5vNpPVJdB58mcLFm3w@mail.gmail.com>
2020-07-04 20:32 ` Writing to a const pointer: is this supposed to happen? Kars Mulder
2020-07-04 20:54   ` Andy Shevchenko
2020-07-05 18:27     ` Kars Mulder
     [not found] <CAHp75Vf9ygQ++DL4ETMy54d=x6oS1qqHLhfyh58f7JCVvM17yA@mail.gmail.com>
2020-07-05 19:38 ` Kars Mulder
     [not found] <CAHp75Ve3m=UK9r2o8bDotQWQBLz-fV8CO_VcTmWjdLW1p5wE-w@mail.gmail.com>
2020-07-05 20:48 ` Kars Mulder

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=0ceda3b41fe446e792fce5ff2634c48f@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=kerneldev@karsmulder.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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.
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).