Another Java related Segmentation violation on WinXP

[John W. Eaton]

On 25-Jan-2008, Michael Goffioul wrote:

| On Jan 25, 2008 9:40 AM, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
| > | d = readtext('data.txt')
| > | d = readtext('data.txt')
| > | d = readtext('data.txt')
| > | d = readtext('data.txt')
| > | d2 = readtext('data.txt')
| >
| > If you notice some problem with Octave's debug features, then I think
| > you'll need to provide a precise description of what you are doing,
| > what you see happening, and what you expect to happen before anyone
| > will be able to help with the problem.
| 
| John, I could trace down the problem with VC debugger and it reveals a
| problem with the scanf methods in oct-stream.cc (at least with MSVC).
| The call is coming from the m-file (input string is "0.00000"):
| 
|      sscanf(s,'%1[ij] %1[+-] %f',3);
| 
| Following code execution, you reach octave_base_stream::do_scanf
| at the cases '[' and '^' (line 1888). The expansion of the macro
| BEGIN_CHAR_CLASS_CONVERSION lead to an octave_scan call
| (line 1555, note that width == 1):
| 
|     OCTAVE_SCAN (is, *elt, tbuf);
| 
| As width is 1, tbuf is a 2-elements char array. I think now comes the
| problem: it seems MSVC chose the execute the octave_scan specialized
| version around line 1138, which simply does a "is >> valptr", without
| taking care of the limited size of the valptr array. Looking at the code,
| I have the impression that it is expected that the octave_scan generic
| version around line 1111 is used instead (this version takes care of the
| limited width of the output buffer).
| 
| You probably have a better understanding of what is the exact expected
| behavior. Could you have a look?

Does the following patch fix the problem for you?

Thanks,

jwe


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
Url: https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080128/d1e7e5a4/attachment.ksh