On Tue, 26 May 2026 at 18:27, Branko Čibej <[email protected]> wrote:

> On 26. 5. 26 18:09, [email protected] wrote:
>
> Author: ivan
> Date: Tue May 26 16:09:14 2026
> New Revision: 1934646
>
> Log:
> Resolve compiler warning (C4312: 'type cast': conversion from 'unsigned int'
> to 'void *' of greater size).
>
> * subversion/libsvn_repos/rev_hunt.c
>   (find_interesting_revisions): Use "1" instead of 0xdeadbeef as non-null
>    pointer for hashtable.
>
> Modified:
>    subversion/trunk/subversion/libsvn_repos/rev_hunt.c
>
> Modified: subversion/trunk/subversion/libsvn_repos/rev_hunt.c
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_repos/rev_hunt.c       Tue May 26 
> 15:32:31 2026        (r1934645)
> +++ subversion/trunk/subversion/libsvn_repos/rev_hunt.c       Tue May 26 
> 16:09:14 2026        (r1934646)
> @@ -1198,7 +1198,7 @@ find_interesting_revisions(apr_array_hea
>        svn_hash_sets(duplicate_path_revs,
>                      apr_psprintf(result_pool, "%s:%ld", path_rev->path,
>                                   path_rev->revnum),
> -                    (void *)0xdeadbeef);
> +                    "1");
>
>        if (path_rev->revnum <= start)
>          break;
>
>
> That dead beef was there because we're using the hash table as a set, not
> a dictionary; only the keys matter. It was intentionally an invalid pointer
> so that the code would crash in a very recognisable way (better than NULL)
> if someone ever tried to dereference the value from the hash table. If
> you're fixing some useless compiler warning – frankly, a promotion that
> doesn't lose data shouldn't warn at all, this is C, after all – then at
> least replace it with NULL instead of a valid pointer that could one day
> hide a real bug.
>

> Yes, I understand that not everyone likes my approach to defence against
> incorrect code. :)
>
>
It's common for Subversion code to use "" as placeholder in apr_hash_t when
it used as set. Some examples:
subversion\libsvn_client\conflicts.c(13293):svn_hash_sets(cswb->unresolved_tree_conflicts,
tc_abspath, "");
subversion\libsvn_client\conflicts.c(13322):svn_hash_sets(unresolved_tree_conflicts,
tc_abspath, "");
subversion\libsvn_delta\editor.c(497):svn_hash_sets(editor->pending_incomplete_children,
child, "");
...

Another common pattern is to use 1 as pointer. For example:
subversion\libsvn_ra_serf\options.c(268):apr_hash_set(session->supported_posts,
"create-txn", 10, (void *)1);
subversion\libsvn_ra_serf\options.c(340):svn_hash_sets(session->supported_posts,
post_val, (void *)1);
...

The 0xdeadbeef was used in only one place. I also would like to note that
0xdeadbeef value is not special and can be valid pointer.

But I'd rather not split hairs on this (rather minor, to my opinion) topic. I
have reverted the change in r1934681.

-- 
Ivan Zhakov

Reply via email to