Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 10 May 2013 17:39:11 +0400
From: Alexander Cherepanov <cherepan@...me.ru>
To: john-dev@...ts.openwall.com
Subject: Re: Constification and format interface clarification

On 2013-05-08 07:58, Solar Designer wrote:
>>> 1. Constification. IMHO it would be good to add a "const" qualifier to function parameters when they are pointers pointing to data which is not modified. It will guarantee that string literals are not modified, make the code more robust, perhaps permit more optimizations etc.
>>
>> http://www.openwall.com/lists/john-dev/2013/02/08/6

I've even posted to this thread but I completely forgot about it;-)

> Thank you for locating this posting in the archive.
>
>> I would be eager to do this if there was significant performance gains to win.
>
> As the posting referenced above indicates, there's absolutely no
> performance gain to expect from constifying the pointers.

After some reading, the conclusion seems to be that, roughly speaking:
- perfomance gain is not expected from constification of pointers;
- perfomance gain could be expected from constification of objects 
(which implies constification of pointers).

Not sure how much gain that could be in JtR.

Another consequence of constification is move of string literals to 
read-only section in executable. Again, not sure if there is any 
perfomance gain.

> There is potential performance gain from use of the restrict keyword,
> but it may also make the code less robust (some of those uses of
> restrict may be bugs, right away or at a later time).

The situation seems to be even more complex. There is potential 
performance gain from use of the restrict qualifier together with the 
const qualifier. There is a good description here:

http://stackoverflow.com/questions/6313730/does-const-correctness-give-the-compiler-more-room-for-optimization

-- 
Alexander Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ