You missed the discussion because it took place in libpd-land: https://github.com/libpd/libpd/issues/336 https://github.com/libpd/libpd/issues/336
It was not a decision taken lightly, but it's necessary as Pd's previous "error()" could conflict with libc "error()". The replacement already existed for sometime, so changing calls to "error(...)" with "pd_error(0, ...)" should be equivalent and not break the external in old versions of Pd.
On Apr 29, 2022, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Fri, 29 Apr 2022 09:51:48 +0200 From: Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: [PD-dev] error missing in Pd 0.52 Message-ID: <96224f3ab47171eff50b17d1507974c6d8b13fd5.camel@gmail.com mailto:96224f3ab47171eff50b17d1507974c6d8b13fd5.camel@gmail.com> Content-Type: text/plain; charset="utf-8"
Hey all
Since 0.52, compiling of some externals fails with an error like:
~~ binfile.c:103:9: error: implicit declaration of function 'error' is invalid in C99 [-Werror,-Wimplicit-function-declaration] error("binfile: Could not create...");
In 0.51-4, the error function was still defined in m_pd.h. Was 'error' deprecated in favor of pd_error? Sorry, if I missed the related discussions, but I feel introducing breaking changes in Pd is generally not done lightly. And I found similar issues in active developments like aoo, so I'm probably not the only one having missed this. Roman
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Fri, 2022-04-29 at 14:02 +0200, Dan Wilcox wrote:
It was not a decision taken lightly,
That's what I thought.
but it's necessary as Pd's previous "error()" could conflict with libc "error()". The replacement already existed for sometime, so changing calls to "error(...)" with "pd_error(0, ...)" should be equivalent and not break the external in old versions of Pd.
So, if the pointer to the object (x) is not available, I can simply set it to 0 (or NULL)? Forgive my noobish question, but Pd doesn't crash when I call that function this way?
Roman
Am 29. April 2022 16:27:04 MESZ schrieb Roman Haefeli reduzent@gmail.com:
"pd_error(0, ...)" should be
equivalent and not break the external in old versions of Pd.
So, if the pointer to the object (x) is not available, I can simply set it to 0 (or NULL)?
Yes. But please do take the opportunity and provide a valid pointer-to-the-object whenever possible, as this allows the user to track down,the source of the error.
Forgive my noobish question, but Pd doesn't crash when I call that function this way?
No, it doesn't crash.
mfg.sfg.jfd IOhannes
On Sat, 2022-04-30 at 07:53 +0200, IOhannes m zmölnig wrote:
Am 29. April 2022 16:27:04 MESZ schrieb Roman Haefeli reduzent@gmail.com:
"pd_error(0, ...)" should be
equivalent and not break the external in old versions of Pd.
So, if the pointer to the object (x) is not available, I can simply set it to 0 (or NULL)?
Yes. But please do take the opportunity and provide a valid pointer-to- the-object whenever possible, as this allows the user to track down,the source of the error.
In some cases, it's not feasible to provide the pointer to the object, for instance in helper functions that don't have it specified as argument. How many levels deep do you think it makes sense to extend the function calls by x?
Roman
Am 30. April 2022 14:41:49 MESZ schrieb Roman Haefeli reduzent@gmail.com:
In some cases, it's not feasible to provide the pointer to the object, for instance in helper functions that don't have it specified as argument. How many levels deep do you think it makes sense to extend the function calls by x?
42.
mfg.sfg.jfd IOhannes
-
Dan Wilcox -
IOhannes m zmölnig -
Roman Haefeli