From tlumley at u.washington.edu  Fri Jul 28 19:48:02 2006
From: tlumley at u.washington.edu (Thomas Lumley)
Date: Fri, 28 Jul 2006 10:48:02 -0700 (PDT)
Subject: [Rd] R uses private function in libc (PR#9107)
In-Reply-To: <20060728173518.BB42D3F03F@slim.kubism.ku.dk>
References: <20060728173518.BB42D3F03F@slim.kubism.ku.dk>
Message-ID: <Pine.LNX.4.64.0607281039530.29331@homer23.u.washington.edu>

>
>
> In any case, as you can see, __libc_stack_end goes away completely by libc
> 2.3.6, and as noted in the follow-up I sent to this bug yesterday, the
> reasons one shouldn't use this symbol are quite clearly stated here:
>
> <http://www.mail-archive.com/debian-glibc at lists.debian.org/msg28253.html>
>

Only up to a point.  We know that __libc_stack_end is not portable, but it 
is being used to do something that is impossible to do portably: check 
whether the C stack is about to overflow. Since there is no way to recover 
from a C stack overflow, being able to prevent it is valuable.

Your fix disables this facility on all Linux systems, which may be 
appropriate for your systems but is clearly undesirable as a change to R. 
The real question is how to detect systems that do provide 
__libc_stack_end and whether there is another non-portable way to do the 
same thing on glibc versions that don't provide it.

 	-thomas



[Rd] R uses private function in libc (PR#9107)
Thomas Lumley