Re: union structures for 64 bit octave

[David Bateman]

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