It's nice to see that the new version of asar is finally done! Some of the new features like #Label, check backcross, etc. are going to be very useful for some of the things I've been working on, and I'm also really glad that the canreadfile/readfile crash has been fixed!
Not sure where to put here... or is it? (Also: Yay! Old layout!)Help us raise funds for the Armed Forces of Ukraine. #ДопомагаємоРазом / #HelpTogether “Even if you personally are so dissatisfied with life that you want the world to end, surely the cruel reality is that it will continue on, unchanging. All the better for someone perfectly content, like me.”
– Aya Shameimaru, Touhou Suzunaan ~ Forbidden Scrollery
Hey! While most of these features won't find any use by a majority of users here, I'm sure that they're a welcome addition for the few that will. Besides, it's always nice to see some bugfixes along the way, too. Well done, you all!
I assume you only mean the errors, not the warning, right? I think the warning was already in previous Asar versions and is a result of that one macro's expansion leading to a negative rep. I assume you're aware of that, so in this version you can now actually disable this warning via
warnings disable W1018
As for the errors, I think those are a result of "fixing" the way the sizeof() function works in Asar, leading to an incompatibility that was overlooked and thus not documentated (might want to either add this to the manual or restore the old code and throw a deprecation warning). In older versions of Asar, this function was just kinda hacked in there. Newer Asar versions, however, have specialized support for string parameters in functions, but this requires passing them to the function delimited by double quotes. Since I cleaned up some of the hacky code in Asar, I've changed this function to work like other functions and take regular string parameters, but forgot to mention this anywhere. So in other words: I think changing those calls from a
should fix the problem. Thanks for pointing that out (hope that doesn't cause any incompatibility with any existing resources on the site - not sure how widely used that function has been here):
It does fix the problem, but (in my opinion) it's kind of a strange workaround. sizeof("tree") makes me think that I'm getting the size of the literal string "tree" (4 bytes) rather than the struct(/label). Isn't there a way to make it support both labels and strings and any other type?
Other than the problem I have encountered though, I'm really, really glad to see that asar is actively being worked on.
-------------------- My blog. I could post stuff now and then
Isn't there a way to make it support both labels and strings and any other type?
That's tricky to answer. I mean from a purely technical standpoint, there probably is (after all scripting languages like Ruby or Python do just that), don't know how easy it would be to add to Asar. I mean Asar doesn't really have a concept of types and it was something I literally added myself to support functions like readfile() etc.
There definitely needs to be a validation at some point, because otherwise there's nothing to prevent a user from passing a number to readfile(), for example, likely making Asar crash (trying to access a double as a string pointer). I think I mainly used the double quote delimiter because it was easy to parse and because it made it possible to check the typing of a parameter before actually using it. I think not requiring the delimiters would require one of two things: either add some kind of guessing algorithm (like "everything that's not a number or a function call is a string"), which seems kinda shaky to me, or let each function evaluate their own parameters themselves, which would be more reliable, though I'm not a fan of that solution (it's basically what sizeof() used to do).
One thing I like about the double quotes is that they're pretty reliable and easy to parse, while also clearly communicating the coder's intention to the program (aka whether they meant a string or something else). I kinda like this from the perspective of code clarity, but on the other hand I'd also like the function to remain backwards-compatible, so I kinda have two conflicting opinions on this. Though one thing I'd definitely like to avoid is what the old sizeof() function did, which basically had its own parameter validation with its own error message. If we added support for untyped parameters back, I'd still want it to work with a generic implementation of parameter validation to make it easy to add new functions to Asar. In other words, this code at the beginning of the sizeof() function
validateparam(structname, 0, Type_String);
should still work as expected and be the only bit of code needed to validate the function's parameter, so if a solution to this could be found, I suppose it would have to be within the context of this validateparam() macro. Can't quite say how simple that would be to do without looking into it further, though.