On 02.07.2012 20:57, Chet Ramey wrote:
On 7/2/12 2:36 PM, Jan Schampera wrote:
The origin of this all was a "bugreport" to me about the manual lying about
no limits on recursion
That's funny.
Aye. A bit of confusion.
--
Be conservative in what you do, be liberal in what you accept from oth
On 7/2/12 2:36 PM, Jan Schampera wrote:
> The origin of this all was a "bugreport" to me about the manual lying about
> no limits on recursion
That's funny.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS,
this all was a "bugreport" to me about the manual lying
about no limits on recursion - it turned out it was massive recursion
and little stack - and a resulting SEGV.
I'm interested in people's thoughts there, like is it okay to just crash
or would a message be better?
On 07/01/2012 07:51 AM, Jan Schampera wrote:
> On 01.07.2012 14:37, Roman Rakus wrote:
>
>> Look for FUNCNEST variable. In recent release it is available.
>
> I more meant the shell interpreter, less the code I can write.
It would be possible to link bash with libsigsegv to install a graceful
st
On 01.07.2012 14:37, Roman Rakus wrote:
Look for FUNCNEST variable. In recent release it is available.
I more meant the shell interpreter, less the code I can write.
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
):
f1() {
f1
}
f1
Currently it runs into a SEGV, where the number of recurions depends
on the stack limit.
On a fast search I found no portable way, but there are ways for
specific platforms, like getrusage() when stack is reported there.
Look for FUNCNEST
Currently it runs into a SEGV, where the number of recurions depends on
the stack limit.
On a fast search I found no portable way, but there are ways for
specific platforms, like getrusage() when stack is reported there.
--
Be conservative in what you do, be liberal in what you accept from
Barry Davis wrote:
> bash# echo $BASH_VERSION
> 2.05b.0(1)-release
> bash# fn() { local x; unset x; echo [EMAIL PROTECTED] ; echo [EMAIL
> PROTECTED]; }
> bash# fn
> 1
>
> ran in a script you get a SEGV
> ran interactively it hangs.
Bash-2.05b is three version
bash# echo $BASH_VERSION
2.05b.0(1)-release
bash# fn() { local x; unset x; echo [EMAIL PROTECTED] ; echo [EMAIL PROTECTED];
}
bash# fn
1
ran in a script you get a SEGV
ran interactively it hangs.
Hello,
On Sat, Mar 08, 2008 at 04:35:02PM -0500, Chet Ramey wrote:
> I'm not inclined to change the current behavior. Bash is perfectly
> happy to allow people to shoot themselves in the foot. We all agree
> that fixed-limit recursion is not the way to go, and I don't think the
> effort involved
k-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables
uname output: Linux tjanouse.englab.brq.redhat.com 2.6.18-53.el5 #1 SMP Wed Oct
10 16:34:02 EDT 2007 i686 i686 i386 GNU/Linux
Machine Type: i686-redhat-linux-gnu
Bash Version: 3.2
Patch Level: 33
Release Statu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to [EMAIL PROTECTED] on 3/6/2008 8:04 AM:
|
| Fix:
| ksh has a fixed recursion depth limit (4096 on 32 bit machines, not
| that many). I'm not sure we want this.
We don't want a fixed recursion limit - it's against GNU philosoph
=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables
uname output: Linux tjanouse.englab.brq.redhat.com 2.6.18-53.el5 #1 SMP Wed Oct
10 16:34:02 EDT 2007 i686 i686 i386 GNU/Linux
Machine Type: i686-redhat-linux-gnu
Bash Version: 3.2
Patch Level: 33
Release Status: release
Descriptio
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAG
14 matches
Mail list logo
