To Pd dev:
After merging commit c019784b83 (get rid of a 3 more bogus (unsigned long) casts) 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.
Alternatively, if it doesn't cause bugs to just cast pointers to long for the purpose of making tags, let's just revert to the old (unsigned long) cast.
cheers Miller
Without any specific knowledge to the case at hand, it should normally be `%p` to print a pointer.
Miller Puckette via Pd-dev wrote on 03/12/2021 04:57:
To Pd dev:
After merging commit c019784b83 (get rid of a 3 more bogus (unsigned long) casts) 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.
Alternatively, if it doesn't cause bugs to just cast pointers to long for the purpose of making tags, let's just revert to the old (unsigned long) cast.
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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/c019784b83f6638a1c4090ce27e6a0... [1] https://github.com/pure-data/pure-data/commit/364d859aa29c1d42be1d42ad81c74b...
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/c019784b83f6638a1c4090ce27e6a0... [1] https://github.com/pure-data/pure-data/commit/364d859aa29c1d42be1d42ad81c74b...
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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/c019784b83f6638a1c4090ce27e6a0...
[1] https://github.com/pure-data/pure-data/commit/364d859aa29c1d42be1d42ad81c74b...
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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/c019784b83f6638a1c4090ce27e6a0...
[1] https://github.com/pure-data/pure-data/commit/364d859aa29c1d42be1d42ad81c74b...
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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...
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...
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...
-
Albert Rafetseder -
Christof Ressi -
Giulio Moro -
Miller Puckette