[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: union structures for 64 bit octave
From: |
David Bateman |
Subject: |
Re: union structures for 64 bit octave |
Date: |
Fri, 03 Jun 2005 09:58:35 +0200 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20040923) |
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 address@hidden
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