mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bernd Petrovitsch <bernd@firmix.at>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: David Howells <dhowells@redhat.com>,
	Linus Torvalds <torvalds@osdl.org>,
	Akinobu Mita <akinobu.mita@gmail.com>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: Mark bitrevX() functions as const
Date: Mon, 11 Dec 2006 18:51:50 +0100	[thread overview]
Message-ID: <1165859510.3308.30.camel@tara.firmix.at> (raw)
In-Reply-To: <Pine.LNX.4.61.0612111828550.28981@yvahk01.tjqt.qr>

On Mon, 2006-12-11 at 18:35 +0100, Jan Engelhardt wrote:
[...]
> I can just second this. What should be marked const is [1]the things 
> pointed to, not [2]the local copy of a function argument.
> 
> This[2] is what I believe almost every other software project does, 

Yes, also for the reason to educate people to actually use "const" as
much as possible - if only to make it for humans clear what may change
somewhere and what not.

> though they often fail at [1]. Or have you seen Glibc trying to pull a
> int strtoul(const char *const nptr, char **const endptr, const int 
> base)? It just makes the prototypes and headers longer without having 

glibc functions like strtoul() are an extremely bad example for this
because there are standards out there which the define the function
signature - so it is often not really the choice of some glibc
developer/maintainer/project lead.
Or you have very old implementations like e.g. the RPC/XDR library which
simply ignore the "const" keyword.

> too much benefit. And maybe the code author may even want to reuse the 
> args directly as walking pointers or countdown integers, for example.

And that is the other problem of such functions and C as such: One wants
the "const char *" in the argument list (if possible) since it allows to
pass "const char *" and "char *". The return value should similarly be
"char *" because then you can use it in the above mentioned way for
"const char *" and "char *".
Alas that gives you a chance to "cast" "const char *" to "char *" and
not even trigger a compiler warning (as opposed a real type cast). Of
course this can be handled/fixed by review but it takes people to
actually do this.
The only sane solution is to get out the same const-ness as passed in -
but this is syntactically not possible in plain simple C.

And the above paragraph is not arguing to remove the keyword "const".

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


      reply	other threads:[~2006-12-11 17:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-11 12:35 David Howells
2006-12-11 12:57 ` Jeff Garzik
2006-12-11 13:37   ` Andreas Schwab
2006-12-11 13:53     ` Jeff Garzik
2006-12-11 13:14 ` David Howells
2006-12-11 13:32   ` Jeff Garzik
2006-12-11 14:18   ` David Howells
2006-12-11 13:25 ` Akinobu Mita
2006-12-11 14:22 ` David Howells
2006-12-11 16:05 ` Linus Torvalds
2006-12-11 16:12 ` David Howells
2006-12-11 16:34   ` Linus Torvalds
2006-12-11 17:35   ` Jan Engelhardt
2006-12-11 17:51     ` Bernd Petrovitsch [this message]

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=1165859510.3308.30.camel@tara.firmix.at \
    --to=bernd@firmix.at \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@osdl.org \
    --cc=dhowells@redhat.com \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®