Fri 11 May 2012 04:39:34 PM UTC, comment #7:
I checked in the following change.
http://hg.savannah.gnu.org/hgweb/octave/rev/edf9ca8a92a8
This problem will be fixed in the upcoming 3.6.2 release.
|
Wed 09 May 2012 06:24:33 AM UTC, comment #6:
Happy belated birthday, bug #33216
This is a very, very corner case. I'd be surprised if anyone other than Jochen Weber has ever run into this.
The issue is that dim_vector::redim will pad with 0 instead of 1 if all of the dimensions of the dim_vector are 0. When you do cell(0,0,1), this in fact is equivalent to cell(0,0) since singleton dimensions are chopped, so it's a cell with all zero dimension vector. The rest of the cell2struct code assumes redim will pad with ones, but in this case it won't. When this assumption breaks in the assertion, you get a SIGABRT or whatever the OS in question does with failed assertions.
I'm working on a fix.
|
Thu 05 May 2011 01:24:33 PM UTC, comment #5:
Hello John and Jaroslav,
From what I can tell, the problem might be that, according to Matlab's standard (which is, as far as I can see, also implemented in Octave), any non-specified "size" (number of indices in any given dimension) beyond the second dimension is automatically considered to be 1 and thus not stored.
Take for example (from my Mac OSX Octave v3.4.0):
It would thus seem necessary that, in case a dimension has to be checked for size, this might best be done by an inline function:
PS: I'm an awful C coder, but you'll get the idea...
Does this help?
/jochen
|
Thu 05 May 2011 04:00:16 AM UTC, comment #4:
Jaroslav, I'm adding you to the CC list for this bug because you added the code that contains the assertion that is failing with the test case
Will you please take a look at this problem?
The changeset that added the assertion is
http://hg.savannah.gnu.org/hgweb/octave/rev/bee1b1a2e29a
I'm not sure what is supposed to happen here. Are the dimensions being set incorrectly? Trailing singletons not handled properly? Or should there just be a special case for empty arrays?
|
Wed 04 May 2011 04:55:23 AM UTC, comment #3:
Confirmed on versions 3.4.0 and on the development branch. I've changed the group of the bug to Crash since this causes a segfault and I've also bumped up the priority.
|
Wed 04 May 2011 02:27:37 AM UTC, comment #2:
It seems that I mistook the error message I got in case I use only one field for a general case.
On my Mac, I get for Octave version 3.4.0:
And under Octave 3.2.3 I get
While a struct with only one field might seem stupid to use, I still think it should not give an error or crash...
/jochen
|
Wed 04 May 2011 01:51:44 AM UTC, comment #1:
Could you be more specific about what you expect the output for init_struct to look like? When running your code I get
which seems correct.
|
Tue 03 May 2011 01:43:24 PM UTC, original submission:
In many of my codefiles I'm currently using the following syntax to produce a 0x0 struct with a fix set of fields (against which I later run checks) but no content (no memory required for pointers, etc.):
In Matlab this works as expected:
- taking the dims of the first input that are not the fieldnames dim (0 and 0) as output dims
- and then creating the output struct with the requested fields
As a workaround I'm currently using a function to initialize structs:
|