On Tue, May 26, 2026 at 6:27 PM 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. :) > > Do I misunderstand something or since when on Earth do we have restrictions to assign a 32bit value to a 64bit variable (not the other way) which doesn't truncate any data? >From the documentation about this warning https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4312 : [[[ This warning detects an attempt to assign a 32-bit value to a 64-bit pointer type, for example, casting a 32-bit int or long to a 64-bit pointer. This can be an unsafe conversion even for pointer values that fit in 32 bits when sign extension occurs. If a negative 32-bit integer is assigned to a 64-bit pointer type, sign extension causes the pointer value to reference a memory address different from the value of the integer. ]]] If as the article says it's about the signed values, would casting it to an unsigned int and then to void* fix it? I mean to do something like: [[[ (void *)(unsigned int)0xdeadbeef ]]] Also the same article suggests an example that it's okay to do the same thing with an int64. I assume the same is true about a size_t. It could also be a way to shut the compiler up. Okay, technically casting a magic number to a pointer is in fact an undefined behaviour but here it is the idea so if anyone ever tries to dereference it, it leads to a crash. I guess NULL also doesn't work because apr_hash_get() already returns NULL if the key is not present. -- Timofei Zhakov
