bugGNU Octave - Bugs: bug #46645, Can't load struct variables that...


bug #46645: Can't load struct variables that use arbitrary fieldnames

Submitted by:  Rik <rik5>
Submitted on:  Wed 09 Dec 2015 07:38:00 PM UTC  
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: otherOperating System: Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Thu 15 Dec 2016 04:08:25 PM UTC, comment #6:

This is another symptom of this bug

The file can be written but it can't be loaded. That shouldn't happen.

This is using 4.3.0+ (dev) version.

Juan Pablo Carbajal <juanpi>
Project Member
Thu 10 Dec 2015 08:43:26 PM UTC, 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

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.

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.

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.

Rik <rik5>
Project Administrator
Wed 09 Dec 2015 09:37:16 PM UTC, comment #4:

Ah, except that message is also about normal variables, not just struct fields, so more extensive surgery might be needed.

John W. Eaton <jwe>
Project Administrator
Wed 09 Dec 2015 09:24:25 PM UTC, comment #3:

Yes, let's eliminate that bogus error message.

John W. Eaton <jwe>
Project Administrator
Wed 09 Dec 2015 08:16:34 PM UTC, comment #2:

Attached is a simple file (bad_struct.var) that contains a struct with a single invalid field name. When I try to load it I get the following.

First, there is a problem because the filename should be reported in the error message. I'll leave that aside for the time being.

Grep'ing for "bogus identifier" shows the only instance is in corefcn/ls-oct-text.cc at line 254.

If you like, we could delete the call to valid_identifier() and then presumably the file would load.

(file #35680)

Rik <rik5>
Project Administrator
Wed 09 Dec 2015 08:00:34 PM UTC, comment #1:

This change was intentional:


As I recall, this wasn't a change I really wanted to make, but one I eventually agreed to do so that people could use structs more like dictionaries.

Maybe what needs to be fixed is the syntax used when saving and loading structs?

John W. Eaton <jwe>
Project Administrator
Wed 09 Dec 2015 07:38:00 PM UTC, original submission:

In version 3.6.4

in version 3.8.2 and all later versions

The dynamically created field name for the struct is no longer validated that it is an appropriate variable name. This is a problem because it is then rather difficult to get the value from the structure because the parser emits an error. If the struct is saved, the file will no longer load back because load() detects that the fieldname is invalid.

Rik <rik5>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #35680:  bad_struct.var added by rik5 (165B - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by juanpi (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by rik5 (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 10 Dec 2015 08:43:26 PM UTCrik5Summaryx.(string) doesn\'t validate that string is valid variable name=>Can't load struct variables that use arbitrary fieldnames
    Wed 09 Dec 2015 08:16:34 PM UTCrik5Attached File-=>Added bad_struct.var, #35680
    Wed 09 Dec 2015 07:38:17 PM UTCrik5Summaryx.(string) doesn\'t validate that string is valid variable name.=>x.(string) doesn't validate that string is valid variable name

    Back to the top

    Powered by Savane 3.1-cleanup1