Re: fopen always returns fid=-1 since revision 8380

[Jaroslav Hajek]

On Mon, Dec 8, 2008 at 11:22 AM, Thomas Treichl <address@hidden> wrote:
> Thomas Treichl schrieb:
>>
>> Hi,
>>
>> with revision 8380, "allow initialized local buffers", there came a
>> strange problem with it. I don't see this problem with revision 8379.
>> Because this changeset is very small I hope somebody can tell me what is
>> going on.
>>
>> If I do
>>
>>  fid = fopen ("file.txt", "w")
>>
>> then I always get a fid=-1 if the file is not there and must be created.
>> If the file is already there then it can be opened correctly for overwriting
>> and I get a valid fid.
>>
>> I noticed that problem because the number of failures while doing "make
>> check" increased rapidly from revision 8379 to 8380, for example
>>
>>  >>>>> processing
>> /Users/Thomas/Development/octave/src/DLD-FUNCTIONS/dlmread.cc
>>  ***** shared file
>>  file = tmpnam ();
>>  fid = fopen (file, "wt");
>>  fwrite (fid, "1, 2, 3\n4, 5, 6\n7, 8, 9\n10, 11, 12");
>>  fclose (fid);
>>  !!!!! test failed
>>  fwrite: invalid stream number = -1shared variables {
>>    file = [](0x0)
>>  }
>>
>> dlmread.cc on its own produces 20 failures on my Mac. Which line of
>> changeset 8380 could make that problems?
>
> If I knew that my first trial would already succeed then I just would have
> sent the solution how it can be solved ;) It seems that I'm the lucky one
> who has a compiler that doesn't like OCTAVE_LOCAL_BUFFER always. A changeset
> for that line that is causing the problem is attached (which is just a copy
> and paste from the old lines that were there in revision 8379).
>

Thomas,

I guess that by 8380 you meant 8379, because 8380 in savannah is "fix
& improve speed of diagonal matrix multiplication". Or is it the other
way around? Please clarify.

Did you rerun ./autogen.sh to regenerate the configure scripts? That
is probably necessary, because the old definition
of macro OCTAVE_LOCAL_BUFFER was directly in config.h.
In any case OCTAVE_LOCAL_BUFFER now *should* work with bools (as
opposed to the old one), therefore your patch is not the right way to
do (unless we become really desperate).
If the answer to the above question is yes, please check for
HAVE_DYNAMIC_AUTO_ARRAYS in config.h.
If it's defined, please try disabling it and compile again (will
recompile just about everything apart from libcruft, unfortunately). I
suspect that dynamic stack arrays can be buggy with some compilers.
What's your compiler, anyway?

regards



> Regards,
>
>  Thomas
>
> # HG changeset patch
> # User Thomas Treichl  <address@hidden>
> # Date 1228726675 -3600
> # Node ID de7ad006fcb5297cb0662a4c71975ad45a37af10
> # Parent  dbe67764e628c6a211bdef4410a69898b8b69723
> One change of OCTAVE_LOCAL_BUFFER.
>
> diff --git a/liboctave/Array.cc b/liboctave/Array.cc
> --- a/liboctave/Array.cc
> +++ b/liboctave/Array.cc
> @@ -1915,7 +1915,10 @@
>     }
>   else
>     {
> -      OCTAVE_LOCAL_BUFFER (T, pvi, ns);
> +      // Don't use OCTAVE_LOCAL_BUFFER (T, pvi, ns); here as it
> +      // doesn't work with bool on some compilers.
> +      Array<T> vi (ns);
> +      T *pvi = vi.fortran_vec ();
>
>       for (octave_idx_type j = 0; j < iter; j++)
>        {
> diff --git a/liboctave/ChangeLog b/liboctave/ChangeLog
> --- a/liboctave/ChangeLog
> +++ b/liboctave/ChangeLog
> @@ -1,3 +1,7 @@
> +2008-12-08  Thomas Treichl  <address@hidden>
> +
> +       * Array.cc: One change of OCTAVE_LOCAL_BUFFER.
> +
>  2008-12-07  Jaroslav Hajek  <address@hidden>
>
>        * mx-inlines.cc (mx_inline_fill_vs): New template function.
>
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz