On Nov 22, 2005, at 10:43 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
in build/mtx_0x2a.c the wrong setup-function is defined.
Ah, thanks... it was a long day. Did you get the other bug report? That one is a bug in the patch... really! ;)
yes, i know though i haven't made any steps to commit a fixed patch yet...
I have a question, why did you reverse the order of the original stantard setup function? i.e. original = mtx_+_setup() altname = setup_mtx_0x2a() I think that just makes things confusing and causes bugs, well, like the one we just talked about.
yes it is confusing but: i want to have a different setup-function for the alternative names; otherwise it would forbid to make an object that is really called "mtx_0x2a". on 2nd thought, this is _almost_ impossible now too, because it is hard (though possible) to have 2 mtx_0x2a.pd_linux lying around (one for the [mtx_*] and one for [mtx_0x2a])
what is more important is, that you cannot start function names with numbers (at least in C) so the [<<<] object (which would expand to "0x3c0x3c0x3c") cannot have a valid setup-function "0x3c0x3c0x3c_setup()"; however "setup_0x3c0x3c0x3c()" is fine.
What about alt_0x3c0x3c0x3c_setup()? That would highlight that its an alternate name, rather than just having an seemingly arbitrary reversal of the "setup" placement. And the function is called sys_load_lib_alt(). That makes more sense in terms of the API.
so i really think, that there should be 2 separate names (if we agree, that it would be a bad idea to rename the standard setupfun-name to setup_***()
Yes, that is more trouble than its worth.
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!