Don't suppress the warnings, let's keep them as a reminder - either on Linux or Windows :-)
I would suggest to look for a general solution to the object ID problem after Pd 0.52. The GitHub issue https://github.com/pure-data/pure-data/issues/1474 already contains a couple of ideas.
Christof
On 03.12.2021 17:27, Miller Puckette wrote:
Or better yet - perhaps just silence the warning in the windows compiler. (I already have to silence a bunch of them that complain when I convert double to float and whatnot).
cheers M
On Fri, Dec 03, 2021 at 08:23:54AM -0800, Miller Puckette via Pd-dev wrote:
So... here's no solution that makes all compilers happy and doesn't get Tcl in a snit... I guess the only way is to make a compiler-dependent macro like #define ptr_to_tag(x) ((unsigned long)(x)) (for gcc) and whatever it is now for windows... I'm OK with punting this for 0.52 and will keep it your way to make sure I keep seeing the problem :)
cheers Miller
On Fri, Dec 03, 2021 at 11:06:54AM +0100, Christof Ressi wrote:
IOhannes has the answer: the resulting string might not be valid Tcl variable name.
For further discussion see: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...