Well, this only affects folks who are abusing the API in teh first place, so I don't think it really matters at all. Since you feel more strongly than I do about it let's do it your way :)
M
On 8/8/25 2:33 PM, Christof Ressi wrote:
On 08.08.2025 13:58, Miller Puckette via Pd-dev wrote:
Again, why would you tag a *private* function as EXTERN in the first place? EXTERN is a macro for *exporting* a function from the Pd binary so that Pd externals can use it. (I guess the better name would have been PD_EXPORT all along.)
Because people are using the damn functions. I wish it weren't so :)
But that's the point! If you don't want people to use a function, don't mark it as EXTERN. Just write an ordinary forward declaration.
Obviously, it's problematic to remove EXTERN from existing functions (even though they are really private) because it can break externals. But we should simply stop marking *new* functions as EXTERN, unless there is a very good reason to do so.
As a side note, there is another big problem with making private functions EXTERN: you can't change the function signature anymore without risking a crash in some external. But the very point of having a private API is that you can freely make changes.
If you just want to make a forward declaration, there is no need for EXTERN at all because functions have extern linkage by default. Just have a look at "s_stuff.h": some functions are marked EXTERN, but others are not.
And that's bad because it's inconsistent.
I don't think so. Functions marked as EXTERN might be potentially useful for externals (even though it might not be "officially" supported). Plain forward declarations are for internal helper/implementation functions.
Anyway, making things "consistent" by DLL-exporting private helper functions doesn't make sense to me. At this point we have to live with the inconsistency.
The issue is just that Linux and macOS export all functions by default, but this can be simply solved by compiling with "-fvisiblity=hidden". See https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/56... . (Linux and macOS really got the defaults wrong in this case.)
I think linux/MacOS have it right - but anyway that's a question of opinion for people who know about compilers to debate, not me.
Hard disagree. If you export all symbols by default, you accidentally export your whole private API for the whole world to use. I don't see any upsides in this.
Christof
cheers M
Cheers,
Christof
cheers M
On 8/7/25 9:12 PM, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some
numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I
would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2721...
- practically all translations have been touched as well (not that
three were any significant change sto the actual translations though) <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2722...
fmasr IOhannes
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...