Skip to content

Magic v2 Internal Code Conversions#24547

Open
leonerd wants to merge 7 commits into
Perl:bleadfrom
leonerd:magic-v2-phase1-conversions
Open

Magic v2 Internal Code Conversions#24547
leonerd wants to merge 7 commits into
Perl:bleadfrom
leonerd:magic-v2-phase1-conversions

Conversation

@leonerd

@leonerd leonerd commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

(This is a dependent PR that requires first that #24163 be merged)

The three new commits here are each individual conversions of static internal 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 associated PERL_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.

@leonerd leonerd added the defer-next-dev This PR should not be merged yet, but await the next development cycle label Jul 8, 2026
@leonerd

leonerd commented Jul 8, 2026

Copy link
Copy Markdown
Contributor Author

All three commits currently introduce new warnings when building with g++, as discussed at some length over in #24508 (comment) and which ultimately lead to the mailing list discussion about using g++ in the first place:
https://www.nntp.perl.org/group/perl.perl5.porters/2026/06/msg271009.html

I still don't have a satisfactory solution to this problem. My personal vote is "lets stop caring about building Perl using g++".

@tonycoz

tonycoz commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

Another one would be argvout_vtbl in doio.c, that's on an IO but it only uses the free and dup callbacks.

@tonycoz

tonycoz commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

It looks reasonable, but I think the g++ build thing needs to be resolved one way or another.

leonerd added 4 commits July 10, 2026 16:26
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.
@leonerd leonerd force-pushed the magic-v2-phase1-conversions branch from b1fde0c to 32d5641 Compare July 10, 2026 15:27
@leonerd

leonerd commented Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

I've opened a new issue (#24553) to discuss the g++ warnings issue

@leonerd leonerd force-pushed the magic-v2-phase1-conversions branch from 32d5641 to 173a190 Compare July 13, 2026 13:00
@leonerd

leonerd commented Jul 13, 2026

Copy link
Copy Markdown
Contributor Author

Ahyes; I had missed the one in doio.c before, but now added. I don't know why it had previously been using PERL_MAGIC_uvar as it didn't seem to be using any of the special get/set behaviour that provides, just free and dup. So it might as well be a MGv2s_BASE now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

defer-next-dev This PR should not be merged yet, but await the next development cycle

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants