linux-kernel - Re: Why is the kfree() argument const?

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:  <4790AF84.2020000@myrealbox.com>
Date:	Fri, 18 Jan 2008 08:54:12 -0500
From:	Andy Lutomirski <luto@...ealbox.com>
To:	linux-kernel@...r.kernel.org
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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?

Giacomo Catenazzi wrote:
> 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.
> 

I'd say this implies the exact opposite.  It almost sounds like the 
compiler is free to change:

void foo(const int *x);
foo(x);
printf("%d", x);

to:

void foo(const int *x);
printf("%d", x);
foo(x);

especially if it can prove that the pointer to x doesn't otherwise 
escape or that foo doesn't call anything that could see the pointer (and 
given that gcc has special magical markings for malloc, one way this 
could be "proven" is to have x be some freshly malloced object.

If foo is kfree, then the above transformation is clearly invalid.

(Note that this isn't just a problem for optimizers -- a programmer 
might expect that passing a pointer to a function that takes a const 
pointer argument does not, in and of itself, change the pointed-to 
value.  Given that const certainly does not mean that no one else 
changes the object, I'm not sure what else it could mean.  kfree does 
not have either property, so I'm don't think it makes sense for it to 
take a const argument.)

--Andy

> 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/
> 

--
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/