3 ms·

Did you see the justifications? For example, > Not only does [INTERN] cons, it either creates a permanent symbol that won't be collected or gives access to in

by kmill 6y ago

Did you see the justifications? For example, > Not only does [INTERN] cons, it either creates a permanent symbol that won't be collected or gives access to internal symbols. This creates opportunities for memory leaks, denial of service attacks, unauthorized access to internals, clashes with other symbols. It even has some advice on using wrappers for INTERN if you really need it. The document has provisions for exceptions to the rules. There's discussion about using EVAL despite the fact the rule says you must not use it. Also, "should avoid" means that you need a good reason, addressed in a comment and code review. Many examples you're probably thinking about are easily containers of elements of like type anyway (allowing mild cases of sum types and such). Though things tend to be more robust with intentionally created data types, I find.

deleted 6y ago
[deleted]
oalae5niMiel7qu 6y ago
All that can be solved by carefully choosing which package you INTERN the symbols into. If you want to avoid having the symbols stick around forever, you can create a temporary package with MAKE-PACKAGE and then use DELETE-PACKAGE when you don't need it anymore.
- kmill 6y ago
  You're right that the rule as stated is incorrect (and I internally corrected it to "it can either create a permanent symbol that won't be collected or give access to internal symbols", so for a moment I didn't know what you were responding to). I think the spirit of the rule is still good, which is raising these sorts of questions at design time and code review: Do you need INTERN? If so, are you INTERNing into the right package? If you are using a temporary package, are you remembering to DELETE-PACKAGE? Do you really need INTERN in an Internet-exposed interface? Does your use of INTERN prevent exposure of sensitive symbol plists to attackers? Does your code rely on private symbols to keep keyword arguments from being used in the public interface, and will INTERN accidentally circumvent it? Is the lifecycle of the temporary package sufficient to prevent DoS? etc.

by kmill 6y ago

deleted 6y ago

[deleted]

oalae5niMiel7qu 6y ago

All that can be solved by carefully choosing which package you INTERN the symbols into. If you want to avoid having the symbols stick around forever, you can create a temporary package with MAKE-PACKAGE and then use DELETE-PACKAGE when you don't need it anymore.

kmill 6y ago
You're right that the rule as stated is incorrect (and I internally corrected it to "it can either create a permanent symbol that won't be collected or give access to internal symbols", so for a moment I didn't know what you were responding to). I think the spirit of the rule is still good, which is raising these sorts of questions at design time and code review: Do you need INTERN? If so, are you INTERNing into the right package? If you are using a temporary package, are you remembering to DELETE-PACKAGE? Do you really need INTERN in an Internet-exposed interface? Does your use of INTERN prevent exposure of sensitive symbol plists to attackers? Does your code rely on private symbols to keep keyword arguments from being used in the public interface, and will INTERN accidentally circumvent it? Is the lifecycle of the temporary package sufficient to prevent DoS? etc.