Forum: NGINX constness of key in ngx_hash_find_

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B9340b8cfd6b4038536e58327ef648c9?d=identicon&s=25 Arvind Jayaprakash (Guest)
on 2008-10-18 20:53
(Received via mailing list)
I was wondering if the "name" argument and also "hash" in the following
functions should be const

void *ngx_hash_find(ngx_hash_t *hash, ngx_uint_t key, u_char *name,
size_t len);
void *ngx_hash_find_wc_head(ngx_hash_wildcard_t *hwc, u_char *name,
size_t len);
void *ngx_hash_find_wc_tail(ngx_hash_wildcard_t *hwc, u_char *name,
size_t len);
void *ngx_hash_find_combined(ngx_hash_combined_t *hash, ngx_uint_t key,
    u_char *name, size_t len);


If that happens, then I can ask for similar changes in
ngx_http_variables{c,h}  :-)
5640e332954fc0006aea97a155ce0afd?d=identicon&s=25 Igor Sysoev (Guest)
on 2008-10-20 10:35
(Received via mailing list)
On Sun, Oct 19, 2008 at 12:13:05AM +0530, Arvind Jayaprakash wrote:

>     u_char *name, size_t len);
>
>
> If that happens, then I can ask for similar changes in
> ngx_http_variables{c,h}  :-)

Do you mean

-void *ngx_hash_find(ngx_hash_t *hash, ..., u_char *name,
+void *ngx_hash_find(const ngx_hash_t *hash, ..., const u_char *name,

?

But what will this improve ?
B9340b8cfd6b4038536e58327ef648c9?d=identicon&s=25 Arvind Jayaprakash (Guest)
on 2008-10-20 14:50
(Received via mailing list)
Igor Sysoev wrote:
> Do you mean
>
> -void *ngx_hash_find(ngx_hash_t *hash, ..., u_char *name,
> +void *ngx_hash_find(const ngx_hash_t *hash, ..., const u_char *name,
>
> But what will this improve ?

This is more of an API design/style question. When passing pointers, if
the function signature declares the argument to be "const type *ptr", it
tells me that the function will not modify the contents of the variable
being passed. For eg: A hash lookup function should never need to modify
either the hash or the key being searched for.

If a function violates this contract, then it results in a compile time
error. If someone tries to forcibly discard the constness using a
typecast, it will result in a warning.

Having the const declarations thus gives people the assurance that the
values being passed will not be modified inside the function. Without
that, I am not sure if the value will get modified unless I read the
implementation.
5640e332954fc0006aea97a155ce0afd?d=identicon&s=25 Igor Sysoev (Guest)
on 2008-10-21 14:43
(Received via mailing list)
On Mon, Oct 20, 2008 at 05:56:24PM +0530, Arvind Jayaprakash wrote:

> tells me that the function will not modify the contents of the variable
> implementation.
OK, I will change this eventually.
B9340b8cfd6b4038536e58327ef648c9?d=identicon&s=25 Arvind Jayaprakash (Guest)
on 2008-12-07 07:15
(Received via mailing list)
Igor Sysoev wrote:
  >> Igor Sysoev wrote:
>>> Do you mean
>>>
>>> -void *ngx_hash_find(ngx_hash_t *hash, ..., u_char *name,
>>> +void *ngx_hash_find(const ngx_hash_t *hash, ..., const u_char *name,
>>>
>>> But what will this improve ?
>
> OK, I will change this eventually.

Here is my first set of changes: I've worked only on the ngx_string.*
files at this point and it seems to break nothing in terms of
compilation.

I've left out a few functions for the following reasons:
_ngx_strlchr_, _ngx_strnstr_, _ngx_strstrn_, _ngx_strcasestrn_ return an
address in the input string; so they are not const
_ngx_utf8_length_, _ngx_utf8_cpystrn_ seem to modify the input string (I
don't know why a length function tries to modify the content of a
string)
_ngx_unescape_uri_ again, I dont know why the source string is being
modified here.

If you find these patches ok, I'll continue my work on rest of the code
base.
This topic is locked and can not be replied to.