A suggestion:
For compatibility with APL2, reserve names beginning with t∆ and s∆. GNU
APL should indicate that trace and stop control are unimplemented when
attempting to set such names to anything other than a numeric vector or
an empty vector.
With 20+ years C experience, IMO using alloca() as a way of allocating
computed sized arrays is good. There are other speed advantages of using
alloca too. Like many C library calls, alloca only works because of the
fact that it is specifically designed to work with a specific tool chain.
That's
Usually the stack frame has a platform specific (!!!) size. If you overflow the stack return adress, stack pointers etc maybe fuzzed.
It is generally a bad idea with heritage from the old VAXen era. IIRC Richie even wrote a paper on dymanic array allocation in the mid-80ies.
Code is bigger and more
Thanks for the work!
I will try the Solaris builds once I get back to the office on Monday.
Regards,
Elias
On 5 April 2014 21:26, Juergen Sauermann wrote:
> Hi,
>
> I hope the Solaris issues are fixed now (SVN 187). Please complain if not.
>
> I decided against alloca() because the descriptio
I read that description too, but they never clarify what those problems may
be. The only thing I can think of is the risk of blowing the stack if the
block is too large, but that is not different from using dynamically
allocated arrays in C like you used to.
Regards,
Elias
On 5 April 2014 21:26,
Hi,
I hope the Solaris issues are fixed now (SVN 187). Please complain if not.
I decided against alloca() because the description on its man page
suggested more problems than advantages.
/// Jürgen
On 04/03/2014 02:55 PM, Elias Mårtenson wrote:
It would, but OpenMP is not supported on it. A
In Command.cc, line 656 the following code is found:
if (dlen == 1 && d_name[0] == '.') continue;
if (dlen == 2 && d_name[0] == '.'
&& d_name[1] == '.') continue;
The references to d_name should be *entry->d_name*.
Also, I stumbled across this one on
