Re: Switch question - yet again!
- Posted by SDPringle Nov 21, 2022
- 7904 views
I'm planning bundle a libcurl wrapper with Euphoria 4.2 (including DLLs on on Windows and rely on system libcurl on *nix). I originally planned to then rebuild std/net/http.e as a wrapper for CURL but after working on FFI I'm thinking I'll just mark std/net/http.e routines as deprecate and leave it at that.
I agree. Because our user base is small, let's leave it in there so we don't infuriate the n users that use it. I wonder whether n is 0.
I wonder if we should adapt this feature to contain table of all potential standard ifdef conditions that start at "off" and get flipped to "on" accordingly. Then we could add a warning for unrecognized conditions. Even add a similarity matching for unknown conditions. Something like "skipping unknown ifdef condition BITS34. did you mean BITS32?" And for truly optional conditions, you could also add without warning += ifdef CONDITION to avoid unnecessary "unknown ifdef CONDITION."
That sounds great, if you have time for that. You could also need a statement to declare for user defined symbols for ifdef. Suppose one wants to create a symbol like NDEBUG for ifdef statements. Today you would simply use
ifdef NDEBUG then print(1, "here\n") end ifdef
But you mostly wouldn't need to remove the warning if there was another statement available like 'declare NDEBUG' that you could use as this:
-- this, in my imaginary Euphoria 4.2, tells the interpreter that NDEBUG might be used in a ifdef export declare NDEBUG
We should ensure Euphoria isn't a language that causes too much friction for folks coming from other languages or using several languages at once. So far I think we've done a good job of that but it's important to keep in mind as we make changes. In this case, constants should be constant and releasing a constant before the end of the program should cause a big red flag. But the backend doesn't check the symbol table for an object's scope during a cleanup. Maybe it should if it's not too much work and won't a performance hit? It would only need to be for user-defined cleanups not all dereferencing in general.
-Greg
As you know, internally when a destructor is added to an integer the representation of integer objects use a structure, which contains the reference count and store the integer as a double or long double, and a pointer to the destructor. This gets returned. If this new object triggers a INT_CHECK operation through trying to optimize a switch then the destructor gets called prematurely. That happens and in this case it seems like it is a use after free or double free error in the backend.
- idea: get rid of destructors on integers. Save yourself a lot of headaches and probably fix other bug scenarios also. The cost is type safety now because all of the io routines would have to accept general atoms for the file handle rather than only integers.
- idea: make switches generate the same code as if x = case1 then ... elsif x = case2 then ... ... end if
- idea: remove all C-int style optimization. Change the front-end system so that objects are never assumed at compile time to be integers. I don't have the skill set for this and would probably introduce more bugs.
- idea: get rid of delete_routine all together. Nobody likes this idea but for completeness I include it here.
