Make Objectify and ObjectifyWithAttributes reject input objects which are not plain lists or records
#5554
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also clarify the documentation -- at least for "standard" GAP; it now misses to mention that atomic lists/records can also be used as input in HPC-GAP, but that seems acceptable, given the state of HPC-GAP and also given that we don't mention specifics for it most of the rest of the regular GAP reference manual. Background: In the distant path we allowed Objectify to be invoked on any kind of GAP list or record, even though it was only intended for plain lists and records. Passing in another kind of list or string could in principle be used to "hack" any object into something different. But that seems like a *bad* idea in general, and there is no clear use case; however, there are cases where this can be done by accident. Hence I tightened this check in early 2020; however, it turned out that there was actually a call to Objectify on a plain string in HAP, so we added a workaround for that. This patch removes that workaround.
fingolfin
force-pushed
the
mh/stricter-Objectify
branch
from
5b7597b
to
28fff9f
Compare
fingolfin
added
the
release notes: use title
|
The tests failed in HAP before, but with the latest HAP update, I did re-run the tests and now they pass. |
ChrisJefferson
approved these changes
Jan 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Also clarify the documentation -- at least for "standard" GAP; it now
misses to mention that atomic lists/records can also be used as input in
HPC-GAP, but that seems acceptable, given the state of HPC-GAP and also
given that we don't mention specifics for it most of the rest of the
regular GAP reference manual.
Background: In the distant path we allowed
Objectifyto be invoked onany kind of GAP list or record, even though it was clearly only intended for
plain lists and records (other kinds of inputs could result in corrupt objects
that could even lead to crashes). Passing in another kind of list or string could
in principle be used to "hack" any object into something different. But
that seems like a bad idea in general, and there is no clear use case;
however, there are cases where this can be done by accident.
Hence I tightened this check in early 2020; however, it turned out that
there was actually a call to
Objectifyon a plain string in HAP, so weadded a workaround for that. This patch removes that workaround.
Of course it should only be merged after a new HAP release with a fix (say gap-packages/hap#117) is released. But then I'd like to merge it ASAP so that we don't regress again.