[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEGFAULT if bash script make "source" for itself
From: |
bogun.dmitriy |
Subject: |
Re: SEGFAULT if bash script make "source" for itself |
Date: |
Thu, 28 Aug 2014 15:42:19 -0700 |
2014-08-28 15:32 GMT-07:00 Eric Blake <eblake@redhat.com>:
> On 08/28/2014 04:11 PM, bogun.dmitriy@gmail.com wrote:
> >> If gcc segfaults because it implements #include via recursion, and I
> >> wrote a recursion loop of #includes into my source, then I'd say the bug
> >> was mine, not gcc's. Just the same as if you write a recursion loop
> >> into your bash program.
> >>
> >> It's not the compiler's fault that input that requests recursion can
> >> abuse the stack. Rather, it is the fault of the input.
> >>
> > Unhanded program termination - is not input problem, it is program
> problem.
> >
> > Looks like gcc programmers not so dumb.
> >
> > $ gcc a.c
> > In file included from a.h:1:0,
> ...
> > from a.h:1,
> > from a.c:1:
> > a.h:1:15: error: #include nested too deeply
>
> If you think the gcc programmers have imposed an artificial limit, raise
> a bug report on their list. Although the GNU Coding Standards request
> no artificial limits, we cannot enforce what other programs choose to do
> or not do by having a conversation on this list.
>
> Also, it's not obvious whether gcc actually implements includes via
> recursion, or whether it uses some other means - so even if they lifted
> their limit for how much is too much include nesting, it's not readily
> obvious whether that would turn into a stack overflow or a more generic
> out of memory error.
>
And they regret to fixing them too?
> Furthermore, the C language standard documents that compilers must allow
> at least a certain amount of nesting, and declares that programs written
> with more than that level of nesting are not strictly defined, and
> therefore a compiler can do what it wants when it gets past that limit.
> Arguably, the fact that gcc errors out gracefully is a product of the
> language definition that they are parsing - the language itself imposes
> a design limit, and once you go beyond the guarantees of the language,
> the compiler does not have to recurse forever. But there is no such
> comparable wording in POSIX for a minimum level of mandatory recursion
> support in the shell.
>
You don't want to hear end user.
>
> >
> > I should make patch and add libsigsegv?
>
> Patches speak louder than words in open source projects. If you are up
> to taking on the task, go for it. You can use GNU m4 and gawk as
> examples of programs that have integrated in libsigsegv stack overflow
> detection.
And what for this mailing list? Don't answer, this have no any sense any
more.
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
- Re: SEGFAULT if bash script make "source" for itself, (continued)
- Re: SEGFAULT if bash script make "source" for itself, Chris Down, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself, bogun.dmitriy, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself, Bob Proulx, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself, bogun.dmitriy, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself, Eric Blake, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself, bogun.dmitriy, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself, Eric Blake, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself,
bogun.dmitriy <=
- Re: SEGFAULT if bash script make "source" for itself, Chris Down, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself, bogun.dmitriy, 2014/08/28
- Re: SEGFAULT if bash script make "source" for itself, Chris Down, 2014/08/28