From maintainers-request at octave dot org Fri Jun 3 03:02:28 2005 Subject: Re: union structures for 64 bit octave From: David Bateman To: Clinton Chee Cc: maintainers at octave dot org Date: Fri, 03 Jun 2005 09:58:35 +0200 Clinton Chee wrote: >Hi David, > >Thanks for your email and the changes you suggested. I'm not too clear >about the function of unwind_protect, why is it trying to protect some >variables. > > > Take the case unwind_protect::begin_frame ("generate_struct_completions"); unwind_protect_int (error_state); unwind_protect_int (warning_state); unwind_protect_bool (discard_error_messages); unwind_protect_bool (discard_warning_messages); discard_error_messages = true; discard_warning_messages = true; octave_value tmp = eval_string (prefix, true, parse_status); unwind_protect::run_frame ("generate_struct_completions"); for variables.cc. eval_string can alter the variables error_state and warning_state, but in the case here we don't want these errors passed to the code above. These variables are therefore protected. >>Does unwind_protect protect octave_idx_type variables? That is the real >>question. If so then the type index should be added to the enum var_type >>and the unions about should become >> >> >> > >To answer your question above, I did a grep on where the code uses >"unwind_protect_int" and the results are shown below. Please correct me >if I'm wrong, but those variables that are protected below, does not >seem to need to be in octave_idx_type. It seems the variables (eg >error_state, warning_state) can be "int"s > > > >oct-hist.cc:490: unwind_protect_int (Vecho_executing_commands); >oct-hist.cc:519: unwind_protect_int (Vecho_executing_commands); >ov-struct.cc:395: unwind_protect_int (Vstruct_levels_to_print); >ov-usr-fcn.cc:342: unwind_protect_int (call_depth); >ov-usr-fcn.cc:417: unwind_protect_int (num_args_passed); >ov-usr-fcn.cc:420: unwind_protect_int (curr_va_arg_number); >parse.cc:4061: unwind_protect_int (error_state); >parse.cc:4062: unwind_protect_int (warning_state); >parse.cc:4111: unwind_protect_int (error_state); >parse.cc:4112: unwind_protect_int (warning_state); >parse.cc:4162: unwind_protect_int (error_state); >parse.cc:4163: unwind_protect_int (warning_state); >parse.cc:5209: unwind_protect_int (error_state); >parse.cc:5210: unwind_protect_int (warning_state); >parse.cc:5403: unwind_protect_int (input_line_number); >parse.cc:5404: unwind_protect_int (current_input_column); >parse.cc:5699: unwind_protect_int (input_line_number); >parse.cc:5700: unwind_protect_int (current_input_column); >parse.cc:5701: unwind_protect_int (end_tokens_expected); >parse.cc:5731: unwind_protect_int (Vecho_executing_commands); >parse.cc:6160: unwind_protect_int (buffer_error_messages); >parse.cc:6293: unwind_protect_int (buffer_error_messages); >pt-arg-list.cc:206: unwind_protect_int (index_position); >pt-except.cc:103: unwind_protect_int (buffer_error_messages); >pt-except.cc:163: unwind_protect_int (error_state); >pt-except.cc:171: unwind_protect_int (tree_return_command::returning); >pt-except.cc:174: unwind_protect_int (tree_break_command::breaking); >variables.cc:447: unwind_protect_int (error_state); >variables.cc:448: unwind_protect_int (warning_state); >variables.cc:491: unwind_protect_int (error_state); > > > Yes, I don't see anything there that needs to be of the type octave_idx_type, so probably the code is ok as is. It might still be a good idea to include the protection function for octave_idx_type though. Cheers David -- David Bateman David dot Bateman at motorola dot com Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary