[PD-dev] how to cast printed pointers? (commit c019784b83 throwing warnings)
Christof Ressi
info at christofressi.com
Fri Dec 3 11:06:54 CET 2021
IOhannes has the answer: the resulting string might not be valid Tcl
variable name.
For further discussion see:
https://github.com/pure-data/pure-data/issues/1474#issuecomment-985386181
On 03.12.2021 10:39, Christof Ressi wrote:
>> NOTE: although %p would be the obvious choice, we can't use it,
>> because the result is platform/compiler dependent. This is not a
>> problem most of the time but it can break in the case of a remote
>> GUI! We really want the pointer ID to look the same on all platforms!
> Hmmm... on a second thought I forgot why this would be a problem...
> the IDs are only generated in the core and GUI app shouldn't care.
>
> So Albert is right, why don't we use %p everywhere?
>
> Christof
>
> On 03.12.2021 10:34, Christof Ressi wrote:
>>> I presume there's a good reason to change the code (what if "long"
>>> is the wrong
>>> size?) but I'd like to figure out a way to do it that doesn't throw
>>> warnings.
>> Ok, now I understand the reason for those few (unsigned long) casts.
>> It's because the printf() family functions will check the format
>> specifier, but the sys_vgui() function, which is used most of the
>> time, does not.
>>
>> However, casting a pointer to (unsigned long) will give a warning on
>> 64-bit Windows, so one of us will always get warnings either way :-)
>>
>> See here for a discussion how to actually fix the problem:
>> https://github.com/pure-data/pure-data/issues/1474
>>
>> NOTE: although %p would be the obvious choice, we can't use it,
>> because the result is platform/compiler dependent. This is not a
>> problem most of the time but it can break in the case of a remote
>> GUI! We really want the pointer ID to look the same on all platforms!
>>
>> Christof
>>
>> On 03.12.2021 09:51, Albert Rafetseder wrote:
>>>> After merging commit c019784b83 (get rid of a 3 more bogus
>>>> (unsigned long) casts)
>>> (Link to commit for reference: [0] )
>>>
>>>> I'm now getting compiler warnings like this:
>>>>
>>>> g_editor.c:1884:73: warning: format ‘%lx’ expects argument of type
>>>> ‘long unsigned int’, but argument 4 has type ‘struct _glist *’
>>>> [-Wformat=]
>>>> 1884 | snprintf(cbuf, MAXPDSTRING - 2,
>>>> "pdtk_canvas_setparents .x%lx", c);
>>>> | ~~^ ~
>>>> | | |
>>>> | | struct _glist *
>>>> | long unsigned int
>>>>
>>>>
>>>> ..
>>>> I presume there's a good reason to change the code (what if "long"
>>>> is the wrong
>>>> size?) but I'd like to figure out a way to do it that doesn't throw
>>>> warnings.
>>> My C has oxidized substantially over time, but I think the p conversion
>>> specifier might be the correct thing to use -- if you can live with the
>>> additional leading "0x" that is caused by its implied "alternate form"
>>> flag, `#`.
>>>
>>> From `man snprintf` on Linux / OS X:
>>>
>>> """
>>> p The void * pointer argument is printed in hexadecimal (as if by
>>> `%#x' or `%#lx').
>>> """
>>>
>>> Trying with the current master [1] which includes the commit above, the
>>> change from `%lx` to `%p` in lines 1884 and 1891 in `g_editor.c` fixes
>>> the warning. (Other warnings/errors remain, and I wouldn't have a clue
>>> what to test to check the outcome anyway.)
>>>
>>> Best,
>>> Albert.
>>>
>>> [0]
>>> https://github.com/pure-data/pure-data/commit/c019784b83f6638a1c4090ce27e6a0036b6bacaa
>>>
>>> [1]
>>> https://github.com/pure-data/pure-data/commit/364d859aa29c1d42be1d42ad81c74bc2fbc76cca
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
More information about the Pd-dev
mailing list