Project

General

Profile

Actions

Bug #3723

closed

Remove unused control frame variable: rb_control_frame_t.block_iseq

Added by pweldon (Peter Weldon) about 14 years ago. Updated over 13 years ago.

Status:
Rejected
Target version:
ruby -v:
ruby 1.9.3dev (2010-08-19 trunk 29056) [i386-mswin32_100]
Backport:
[ruby-core:31786]

Description

=begin
rb_control_frame_t.block_iseq does not appear to serve any purpose and can possibly be removed.
=end


Related issues 1 (0 open1 closed)

Related to Backport192 - Backport #3712: SEGV fails to produce stack dump / backtrace in debug buildClosed08/19/2010Actions
Actions #1

Updated by naruse (Yui NARUSE) about 14 years ago

  • Status changed from Open to Assigned
  • Assignee set to ko1 (Koichi Sasada)

=begin
As you said, it seems useless variable.

But if block_iseq of rb_control_frame_t is simply removed, it breaks ABI compatibility.

I assign this to ko1.
=end

Actions #2

Updated by naruse (Yui NARUSE) about 14 years ago

  • Status changed from Assigned to Rejected

=begin
I talked this with ko1.
It is used from rb_block_t.iseq, so it can't be removed.
=end

Actions #3

Updated by pweldon (Peter Weldon) about 14 years ago

=begin
I apologise, I did not understand the connection between rb_control_frame_t and rb_block_t. I see now that these macros are used to access rb_control_frame_t members via a rb_block_t:

vm_core.h:
#define RUBY_VM_GET_BLOCK_PTR_IN_CFP(cfp) ((rb_block_t *)(&(cfp)->self))
#define RUBY_VM_GET_CFP_FROM_BLOCK_PTR(b)
((rb_control_frame_t *)((VALUE *)(b) - 5))

The rb_control_frame_t comments in vm_core.h now also make sense to me. Thank you for helping me understand.

=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0