[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #46645] Can't load struct variables that use a
From: |
Rik |
Subject: |
[Octave-bug-tracker] [bug #46645] Can't load struct variables that use arbitrary fieldnames |
Date: |
Thu, 10 Dec 2015 20:43:27 +0000 |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0 |
Update of bug #46645 (project octave):
Summary: x.(string) doesn't validate that string is valid
variable name => Can't load struct variables that use arbitrary fieldnames
_______________________________________________________
Follow-up Comment #5:
More extensive surgery will be needed. The function read_text_data() is
called, essentially recursively, when trying to load a struct variable. The
first time through the function it identifies that the type is a struct and
then calls read_text_data for each of the "sub-variables" which are the fields
of the struct.
The obvious way around this is to get the variable name, and then delay input
validation, and get the variable type. After that one could decide whether to
validate the variable name fully or not. But, we would also need to change
the function prototype for read_text_data (and the others like
read_binary_data) so that we could pass down a flag to indicate that we are
still in a struct.
The backtrace is
#0 read_text_data (is=..., filename=..., address@hidden: false,
tc=..., count=0)
at libinterp/corefcn/ls-oct-text.cc:255
#1 0x00007ffff6ca95ea in octave_scalar_struct::load_ascii
(this=0x7fffd04bb9e0, is=...)
at libinterp/octave-value/ov-struct.cc:1401
#2 0x00007ffff7067c26 in octave_value::load_ascii (this=0x7fffd693b0b0,
is=...)
at ./libinterp/octave-value/ov.h:1264
#3 0x00007ffff7067323 in read_text_data (is=..., filename=...,
address@hidden: false, tc=...,
count=0) at libinterp/corefcn/ls-oct-text.cc:281
#4 0x00007ffff703c7a5 in do_load (stream=..., orig_fname=..., format=...,
flt_fmt=oct_mach_info::flt_fmt_unknown, list_only=false, swap=false,
verbose=false, argv=...,
argv_idx=2, argc=2, nargout=0) at libinterp/corefcn/load-save.cc:368
#5 0x00007ffff703e6a3 in Fload (args=..., nargout=0) at
libinterp/corefcn/load-save.cc:856
Incidentally, the problem with the filename not being printed is caused by the
fact that we vector through load_ascii() in ov.h which has the following
prototype.
bool load_ascii (std::istream& is) { return rep->load_ascii (is); }
Because we are passing through only the istream we don't have the filename
when we actually call read_text_data again. The prototype for read_text_data
is shown below.
read_text_data (std::istream& is, const std::string& filename, bool& global,
octave_value& tc, octave_idx_type count)
The simplest thing is probably to change the reporting and don't report
information about the file name. This is fine for interactive use where the
load command is proximate in time to the error message. For scripts, it's not
as great because there might be multiple load commands in an m-file and you
would need to set debug_on_error(1) in order to figure out which load command
generated an error.
Other possibilities include changing the function prototypes to use
octave_stream which has the name of the file as a member of the class. Or we
could stick with istream, but change the function prototype of load_ascii to
have an additional argument.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?46645>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/