lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47906133.6010301@cateee.net>
Date:	Fri, 18 Jan 2008 09:20:03 +0100
From:	Giacomo Catenazzi <cate@...eee.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	David Schwartz <davids@...master.com>,
	Johannes Weiner <hannes@...urebad.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	clameter@....com, penberg@...helsinki.fi
Subject: Re: Why is the kfree() argument const?

And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )

Page 75 of C99 rationale:

Type qualifiers were introduced in part to provide greater control over optimization. Several
important optimization techniques are based on the principle of "cacheing": under certain
circumstances the compiler can remember the last value accessed (read or written) from a
location, and use this retained value the next time that location is read. (The memory, or
"cache", is typically a hardware register.) If this memory is a machine register, for instance, the
code can be smaller and faster using the register rather than accessing external memory.
The basic qualifiers can be characterized by the restrictions they impose on access and
cacheing:

const          No writes through this lvalue. In the absence of this qualifier, writes may occur
               through this lvalue.

volatile       No cacheing through this lvalue: each operation in the abstract semantics must
               be performed (that is, no cacheing assumptions may be made, since the location
               is not guaranteed to contain any previous value). In the absence of this qualifier,
               the contents of the designated location may be assumed to be unchanged except
               for possible aliasing.

restrict       Objects referenced through a restrict-qualified pointer have a special
               association with that pointer. All references to that object must directly or
               indirectly use the value of this pointer. In the absence of this qualifier, other
               pointers can alias this object. Cacheing the value in an object designated through
               a restrict-qualified pointer is safe at the beginning of the block in which the
               pointer is declared, because no pre-existing aliases may also be used to reference
               that object. The cached value must be restored to the object by the end of the
               block, where pre-existing aliases again become available. New aliases may be
               formed within the block, but these must all depend on the value of the
               restrict-qualified pointer, so that they can be identified and adjusted to refer
               to the cached value. For a restrict-qualified pointer at file scope, the block
               is the body of main.

ciao
	cate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ