Ticket #1697 (new deprecation)

Opened 12 years ago

Last modified 10 years ago

Remove the open and close opcodes

Reported by: dukeleto Owned by: whiteknight
Priority: normal Milestone:
Component: core Version: master
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: all


The open and close opcodes are redundant and since the IO ops became dynops, have subtle problems, as found by PL/Parrot:

arg count mismatch: op #1119 'open' needs 17820 given 3

 http://groups.google.com/group/parrot-dev/browse_thread/thread/d99dfeabda257cf1  http://groups.google.com/group/parrot-dev/browse_thread/thread/b8f6e3f2e0f285ff

Uses of the open/close opcode can easily be changed to use the open/close methods on the File or FileHandle PMC.

Change History

in reply to: ↑ description   Changed 12 years ago by plobsing

Replying to dukeleto:

arg count mismatch: op #1119 'open' needs 17820 given 3  http://groups.google.com/group/parrot-dev/browse_thread/thread/d99dfeabda257cf1  http://groups.google.com/group/parrot-dev/browse_thread/thread/b8f6e3f2e0f285ff

While I agree that these opcodes would probably be better off as methods, I don't think this is an appropriate solution to the stated problem. PL/Parrot and/or any security conscious project *will* need to deal with whitelisting/blacklisting dynops eventually. This is a bandaid solution to that problem.

  Changed 11 years ago by jkeenan

Do we even have open or close opcodes any more?

$ grep -niE '(open|close)' src/ops/*
src/ops/core.ops:1220:accessible from PASM if F<dlopenflags.pasm> is included.  The current
src/ops/core.ops:1225:=item PARROT_DLOPEN_GLOBAL
src/ops/experimental.ops:46:If you rely on any of these opcodes, please open a
src/ops/io.ops:56:    /* Workaround for older msvcrt and openbsd. TT #313 */
src/ops/io.ops:99:    /* Workaround for older msvcrt and openbsd. TT #313 */

If not, can we close this ticket?

Thank you very much.


  Changed 11 years ago by NotFound

Yes, they are in dynoplibs/io.ops

  Changed 11 years ago by dukeleto

These have been eligible to be removed for a while. +1 to yanking them.

  Changed 11 years ago by cotto

I'm fine with this, provided we make ourselves aware of and mitigate the potential disruption to users. Rakudo (at least) does make use of the io dynops and would need to be updated before we could fully remove the open and close ops.

  Changed 10 years ago by whiteknight

  • owner set to whiteknight
  • version changed from 2.5.0 to master

+1 to yank. I can start a branch for this soon, to get Rakudo up to speed with it before we drop anything on master.

Note: See TracTickets for help on using tickets.