Magic v2 Internal Code Conversions#24547
Conversation
|
All three commits currently introduce new warnings when building with I still don't have a satisfactory solution to this problem. My personal vote is "lets stop caring about building Perl using g++". |
|
Another one would be argvout_vtbl in doio.c, that's on an IO but it only uses the free and dup callbacks. |
|
It looks reasonable, but I think the g++ build thing needs to be resolved one way or another. |
The existing `MAGIC` and `MGVTBL` structures are insufficiently extensible, because they lack any embedded type information, or any version numbering by which new abilities can be added in a backwards-compatible way. Commit 6d97c86 managed to free a single bit in the `mg_flags` field; it is this bit that we use to indicate that the `MAGIC` structure refers to version 2 of Magic. The new structures are defined in a way that should be much easier to permit updates in future; primarily by the presence of a version number in the `ver` field, and the set of trigger functions in the `shape` field. In this way, we hope to be able to extend the abilities of magic in the future by adding new structure shapes as well as new trigger functions.
b1fde0c to
32d5641
Compare
|
I've opened a new issue (#24553) to discuss the |
32d5641 to
173a190
Compare
|
Ahyes; I had missed the one in |
(This is a dependent PR that requires first that #24163 be merged)
The three new commits here are each individual conversions of
staticinternal magic types to use magic v2. None of them are strictly "required", but we felt it useful to have some code sitting around that uses magic-v2, as a demonstration that it works. These ones were picked because they're all static and don't have associatedPERL_MAGIC_*constants anyway, so there's no way that external code / CPAN / DarkPAN would be aware of them in any way that this could break.