Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #24032 > unrolled thread

signal() anomaly

Back to article view | Back to comp.lang.c

Contents

  signal() anomaly hip cat <nospam@nospam.com> - 2012-07-31 20:13 +0000
    Re: signal() anomaly Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-31 16:35 -0400
      Re: signal() anomaly hip cat <nospam@nospam.com> - 2012-08-01 18:59 +0000
      Re: signal() anomaly Nick Bowler <nbowler@draconx.ca> - 2012-08-01 20:14 +0000
    Re: signal() anomaly falk@rahul.net (Edward A. Falk) - 2012-07-31 22:12 +0000
      Re: signal() anomaly hip cat <nospam@nospam.com> - 2012-08-01 18:58 +0000
        Re: signal() anomaly James Kuyper <jameskuyper@verizon.net> - 2012-08-01 15:33 -0400
          Re: signal() anomaly hip cat <nospam@nospam.com> - 2012-08-01 20:47 +0000
            Re: signal() anomaly Paul <nospam@needed.com> - 2012-08-01 17:34 -0400
              Re: signal() anomaly Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-08-02 06:34 +0200
                Re: signal() anomaly Paul <nospam@needed.com> - 2012-08-02 07:10 -0400
            Re: signal() anomaly Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-01 18:07 -0400
              Re: signal() anomaly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-02 00:15 +0100
                Re: signal() anomaly Nick Bowler <nbowler@draconx.ca> - 2012-08-02 00:05 +0000
                  Re: signal() anomaly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-02 02:47 +0100
            Re: signal() anomaly James Kuyper <jameskuyper@verizon.net> - 2012-08-01 18:13 -0400
            Re: signal() anomaly James Kuyper <jameskuyper@verizon.net> - 2012-08-01 18:14 -0400
            Re: signal() anomaly Nobody <nobody@nowhere.com> - 2012-08-02 12:52 +0100
        Re: signal() anomaly Angel <angel+news@spamcop.net> - 2012-08-01 19:41 +0000
        Re: signal() anomaly Kenneth Brody <kenbrody@spamcop.net> - 2012-08-01 16:16 -0400
        Re: signal() anomaly Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-01 16:33 -0400
        Re: signal() anomaly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-02 00:22 +0100
        Re: signal() anomaly Stephen Sprunk <stephen@sprunk.org> - 2012-08-02 00:55 -0500
          Re: signal() anomaly Ike Naar <ike@sverige.freeshell.org> - 2012-08-02 07:01 +0000
        Re: signal() anomaly Öö Tiib <ootiib@hot.ee> - 2012-09-08 20:53 -0700
    Re: signal() anomaly Nobody <nobody@nowhere.com> - 2012-08-01 18:06 +0100
      Re: signal() anomaly Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 13:44 -0700
    Re: signal() anomaly Kleuske <kleuske@nowhere.net> - 2012-08-02 20:52 +0000

Page 1 of 2  [1] 2  Next page →

#24032 — signal() anomaly

What up

I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference 
a null pointer my program still crashes out with segfault SIGSEGV. What 
gives?

Communicate laterz ++

[toc] | [next] | [standalone]

#24033

On 7/31/2012 4:13 PM, hip cat wrote:
> What up
>
> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
> a null pointer my program still crashes out with segfault SIGSEGV. What
> gives?

     Did you check that the signal() call succeeded?  That is,
was the returned value SIG_ERR or something else?

     On POSIX systems, ignoring SIGSEGV produces undefined behavior.
The C Standard isn't quite so clear to me: It's U.B. if a signal
handler for SIGSEGV returns (7.14.1.1p3), but SIG_IGN is not a
"signal handler" under the definition of 7.14.1.1p2.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#24085

On Tue, 31 Jul 2012 16:35:41 -0400, Eric Sosman wrote:

> On 7/31/2012 4:13 PM, hip cat wrote:
>> What up
>>
>> I've used signal to set SIGSEGV to SIG_IGN. But when I later
>> dereference a null pointer my program still crashes out with segfault
>> SIGSEGV. What gives?
> 
>      Did you check that the signal() call succeeded?  That is,
> was the returned value SIG_ERR or something else?
> 
>      On POSIX systems, ignoring SIGSEGV produces undefined behavior.
> The C Standard isn't quite so clear to me: It's U.B. if a signal handler
> for SIGSEGV returns (7.14.1.1p3), but SIG_IGN is not a "signal handler"
> under the definition of 7.14.1.1p2.

Word Eric,

The return value is 0.

Communicate laterz ++

[toc] | [prev] | [next] | [standalone]

#24091

On Tue, 31 Jul 2012 16:35:41 -0400, Eric Sosman wrote:

> On 7/31/2012 4:13 PM, hip cat wrote:
>> What up
>>
>> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>> a null pointer my program still crashes out with segfault SIGSEGV. What
>> gives?
> 
>      Did you check that the signal() call succeeded?  That is,
> was the returned value SIG_ERR or something else?
> 
>      On POSIX systems, ignoring SIGSEGV produces undefined behavior.

POSIX is a bit more specific than that.  But regardless...

> The C Standard isn't quite so clear to me: It's U.B. if a signal
> handler for SIGSEGV returns (7.14.1.1p3), but SIG_IGN is not a
> "signal handler" under the definition of 7.14.1.1p2.

...the C standard doesn't need to be any more explicit on this matter.
The behaviour is undefined because the program has dereferenced an
invalid (null) pointer.  The handling of SIGSEGV is irrelevant.

[toc] | [prev] | [next] | [standalone]

#24035

In article <jv9e9e$bj3$1@speranza.aioe.org>,
hip cat  <nospam@nospam.com> wrote:
>What up
>
>I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference 
>a null pointer my program still crashes out with segfault SIGSEGV. What 
>gives?

I am amused and curious -- what did you *want* to happen on a null
pointer dereference?

-- 
	-Ed Falk, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

[toc] | [prev] | [next] | [standalone]

#24084

On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
> In article <jv9e9e$bj3$1@speranza.aioe.org>, hip cat 
> <nospam@nospam.com> wrote:
>>What up
>>
>>I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>>a null pointer my program still crashes out with segfault SIGSEGV. What
>>gives?
> 
> I am amused and curious -- what did you *want* to happen on a null
> pointer dereference?

Word Ed,

My code has a certain pointer that sometimes unexpectedly becomes null. 
It would be a lot of work to find every place the pointer gets 
dereferenced and add a null check. So I want to just ignore it by 
catching the signal.

Communicate laterz ++

[toc] | [prev] | [next] | [standalone]

#24087

On 08/01/2012 02:58 PM, hip cat wrote:
> On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
>> In article <jv9e9e$bj3$1@speranza.aioe.org>, hip cat 
>> <nospam@nospam.com> wrote:
>>> What up
>>>
>>> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>>> a null pointer my program still crashes out with segfault SIGSEGV. What
>>> gives?
>>
>> I am amused and curious -- what did you *want* to happen on a null
>> pointer dereference?
> 
> Word Ed,
> 
> My code has a certain pointer that sometimes unexpectedly becomes null.

Rather than trying to make this work, you should be trying to find out
why the pointer is becoming null.

> It would be a lot of work to find every place the pointer gets 
> dereferenced and add a null check. So I want to just ignore it by 
> catching the signal.

Well, as "Nobody" has already pointed out, that's not an option. Using
SIG_IGN for this has undefined behavior. So does registering your own
SIGSEGV "handler" that doesn't bother to actually do anything, and
simply returns. Therefore, you're going to have to either insert the
null checks, or let the program abort() - your choice.

[toc] | [prev] | [next] | [standalone]

#24095

On Wed, 01 Aug 2012 15:33:20 -0400, James Kuyper wrote:
> On 08/01/2012 02:58 PM, hip cat wrote:
>> On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
>>> In article <jv9e9e$bj3$1@speranza.aioe.org>, hip cat
>>> <nospam@nospam.com> wrote:
>>>> What up
>>>>
>>>> I've used signal to set SIGSEGV to SIG_IGN. But when I later
>>>> dereference a null pointer my program still crashes out with segfault
>>>> SIGSEGV. What gives?
>>>
>>> I am amused and curious -- what did you *want* to happen on a null
>>> pointer dereference?
>> 
>> Word Ed,
>> 
>> My code has a certain pointer that sometimes unexpectedly becomes null.
> 
> Rather than trying to make this work, you should be trying to find out
> why the pointer is becoming null.
> 
>> It would be a lot of work to find every place the pointer gets
>> dereferenced and add a null check. So I want to just ignore it by
>> catching the signal.
> 
> Well, as "Nobody" has already pointed out, that's not an option. Using
> SIG_IGN for this has undefined behavior. So does registering your own
> SIGSEGV "handler" that doesn't bother to actually do anything, and
> simply returns. Therefore, you're going to have to either insert the
> null checks, or let the program abort() - your choice.

Word Jim,

I think Eric was right on the money asking about the return value. If the 
signal() call returns success, but the "ignore" is ignored, I say that's 
a bug in the C library. I think I'll file a bug report against glibc.

Communicate laterz ++

[toc] | [prev] | [next] | [standalone]

#24098

hip cat wrote:

> 
> Word Jim,
> 
> I think Eric was right on the money asking about the return value. If the 
> signal() call returns success, but the "ignore" is ignored, I say that's 
> a bug in the C library. I think I'll file a bug report against glibc.
> 
> Communicate laterz ++

For your amusement.

http://efreedom.com/Question/1-2663456/Write-Signal-Handler-Catch-SIGSEGV

You can step around that busted line of code. But
you'd have to be Yoda to succeed.

    Paul

[toc] | [prev] | [next] | [standalone]

#24110

Paul wrote:
> hip cat wrote:
>
>>
>> Word Jim,
>>
>> I think Eric was right on the money asking about the return value. If
>> the signal() call returns success, but the "ignore" is ignored, I say
>> that's a bug in the C library. I think I'll file a bug report against
>> glibc.
>>
>> Communicate laterz ++
>
> For your amusement.
>
> http://efreedom.com/Question/1-2663456/Write-Signal-Handler-Catch-SIGSEGV
>
> You can step around that busted line of code. But
> you'd have to be Yoda to succeed.
>
> Paul

It is quite possible. In Linux, at least, where the machine state is 
passed to the signal handler. You can find out the instruction that 
caused the exception and advance the instruction pointer to point to the 
next one, thus avoiding subsequent segfaults. This is rather difficult 
with the usual variable-length opcodes, and would require limited 
instruction decoding.
...
Of course, that does not mean that your program will do anything 
meaningful. Register contents will end up undefined etc...

[toc] | [prev] | [next] | [standalone]

#24122

Johann Klammer wrote:
> Paul wrote:
>> hip cat wrote:
>>
>>>
>>> Word Jim,
>>>
>>> I think Eric was right on the money asking about the return value. If
>>> the signal() call returns success, but the "ignore" is ignored, I say
>>> that's a bug in the C library. I think I'll file a bug report against
>>> glibc.
>>>
>>> Communicate laterz ++
>>
>> For your amusement.
>>
>> http://efreedom.com/Question/1-2663456/Write-Signal-Handler-Catch-SIGSEGV
>>
>> You can step around that busted line of code. But
>> you'd have to be Yoda to succeed.
>>
>> Paul
> 
> It is quite possible. In Linux, at least, where the machine state is 
> passed to the signal handler. You can find out the instruction that 
> caused the exception and advance the instruction pointer to point to the 
> next one, thus avoiding subsequent segfaults. This is rather difficult 
> with the usual variable-length opcodes, and would require limited 
> instruction decoding.
> ...
> Of course, that does not mean that your program will do anything 
> meaningful. Register contents will end up undefined etc...

I could have mentioned as well, that debuggers are good at noting
such things, and can also alert you when one happens. You can even
single-step your new program, and watch the value of the variable
in question. The debuggers on various platforms, vary in how
"friendly" they are, and some of them, I can't run at all.
Can't seem to succeed in getting them to do anything. The last
one I ran, was in Visual Studio, and that seemed OK. Almost worthwhile,
compared to sprinkling printfs all over the place.

    Paul

[toc] | [prev] | [next] | [standalone]

#24099

On 8/1/2012 4:47 PM, hip cat wrote:
>[...]
> I think Eric was right on the money asking about the return value. If the
> signal() call returns success, but the "ignore" is ignored, I say that's
> a bug in the C library. I think I'll file a bug report against glibc.

     If signal(SIGSEGV, SIG_IGN) does nothing and indicates success,
you may have a case.  But if it can't in fact do anything, the fix
will be to have it return SIG_ERR and tell you so.  That is, you're
still not going to get the signal ignored!  (Nor should you, as has
been pointed out elsethread.)

     You mention glibc, which means you're probably on a POSIX-like
system.  If so, the program's behavior is undefined if SIGSEGV
occurs while it's being ignored -- and among the possible undefined
behaviors is "SIGSEGV crashes the program anyhow."  So from a POSIX
perspective there's no bug: It might be a nice enhancement to have
signal() return SIG_ERR, but returning 0 doesn't reach "bug" level.

     What remains unclear (to me) is how the C Standard rules on this
issue.  We know the behavior is undefined if SIGSEGV goes to a handler
and the handler returns, but SIG_IGN isn't a "handler."  So it's
possible the C Standard and POSIX disagree here -- but it would not
surprise me one little bit to learn that I've overlooked something.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#24102

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
<snip>
>     What remains unclear (to me) is how the C Standard rules on this
> issue.  We know the behavior is undefined if SIGSEGV goes to a handler
> and the handler returns, but SIG_IGN isn't a "handler."  So it's
> possible the C Standard and POSIX disagree here -- but it would not
> surprise me one little bit to learn that I've overlooked something.

I don't think there is anything explicit, but neither can I see any room
for disagreement but, first, a nit: the behaviour is not undefined if
the signal is the result of a call to 'raise'.  The signal can be
handled or ignored and, if handled, the handler can return.  This is
true of both C and POSIX.

When the signal is not the result of a call to 'raise', both C and POSIX
agree that the handler, if it is set, must not return.  Thus the only
possible disagreement could be when the signal was not raised explicitly
and the signal is being ignored.  As you say, POSIX declares this
explicitly to be UB, but C does not.

However, C does say that a SIGSEGV results from "an invalid access to
storage".  It's hard to imagine an invalid access that does not already
result in UB as far as C is concerned.  Some will be explicit (like *0)
but, since the standard defines what valid accesses are, all the rest
(that are not explicitly UB) must be UB by omission.  And if the access
has already made the behaviour of the program undefined, no signal
setting can alter that.

It's not exactly cast-iron, but I can't see anything in gap between the
two standards on this issue.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24104

On Thu, 02 Aug 2012 00:15:39 +0100, Ben Bacarisse wrote:

> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> <snip>
>>     What remains unclear (to me) is how the C Standard rules on this
>> issue.  We know the behavior is undefined if SIGSEGV goes to a handler
>> and the handler returns, but SIG_IGN isn't a "handler."  So it's
>> possible the C Standard and POSIX disagree here -- but it would not
>> surprise me one little bit to learn that I've overlooked something.
> 
> I don't think there is anything explicit, but neither can I see any room
> for disagreement but, first, a nit: the behaviour is not undefined if
> the signal is the result of a call to 'raise'.  The signal can be
> handled or ignored and, if handled, the handler can return.  This is
> true of both C and POSIX.

I'm not so certain if it is ok for such a handler to return normally in
standard C.  POSIX provides an explicit exception for a SIGSEGV handler
which returns in the case where the signal was generated by a call to
kill, sigqueue or raise.  (Curiously, pthread_kill is missing from that
list).  However, there is no similar language in the C11 standard,
leading me to believe that the behaviour is undefined regardless of
whether the signal was the result of a call to raise or not.  I've
quoted the relevant passages from C11[1] and SUSv4[2] for comparison.

[1] [C11§7.4.1.1#3] When a signal occurs and func points to a
    function, ... if and when the function returns, if the value
    of sig is SIGFPE, SIGILL, SIGSEGV, or any other implementation-
    defined value corresponding to a computational exception, the
    behaviour is undefined; otherwise ...

[2] [SUSv4§2.4.3] The behavior of a process is undefined after it
    returns normally from a signal-catching function for a SIGBUS,
    SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(),
    sigqueue(), or raise().

Nothing in the C11 passage suggests that it is acceptable to return from
a SIGSEGV handler that was invoked due to a call to raise.  Moreover,
from the above passage, this implies that a conforming implementation
could define every single signal to "correspond to a computational
exception".  Therefore, no strictly conforming program may ever return
normally from any signal handler.

Perhaps this is an oversight in the standard, or it's specified
elsewhere and I've simply missed it.  But anyway, all this reinforces
my belief that signals, as described by the C standards, are too
ill-specified to be useful at all, and may as well not be there.

[toc] | [prev] | [next] | [standalone]

#24108

Nick Bowler <nbowler@draconx.ca> writes:

> On Thu, 02 Aug 2012 00:15:39 +0100, Ben Bacarisse wrote:
>
>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>> <snip>
>>>     What remains unclear (to me) is how the C Standard rules on this
>>> issue.  We know the behavior is undefined if SIGSEGV goes to a handler
>>> and the handler returns, but SIG_IGN isn't a "handler."  So it's
>>> possible the C Standard and POSIX disagree here -- but it would not
>>> surprise me one little bit to learn that I've overlooked something.
>> 
>> I don't think there is anything explicit, but neither can I see any room
>> for disagreement but, first, a nit: the behaviour is not undefined if
>> the signal is the result of a call to 'raise'.  The signal can be
>> handled or ignored and, if handled, the handler can return.  This is
>> true of both C and POSIX.
>
> I'm not so certain if it is ok for such a handler to return normally in
> standard C.  POSIX provides an explicit exception for a SIGSEGV handler
> which returns in the case where the signal was generated by a call to
> kill, sigqueue or raise.  (Curiously, pthread_kill is missing from that
> list).  However, there is no similar language in the C11 standard,
> leading me to believe that the behaviour is undefined regardless of
> whether the signal was the result of a call to raise or not.  I've
> quoted the relevant passages from C11[1] and SUSv4[2] for comparison.
>
> [1] [C11§7.4.1.1#3] When a signal occurs and func points to a
>     function, ... if and when the function returns, if the value
>     of sig is SIGFPE, SIGILL, SIGSEGV, or any other implementation-
>     defined value corresponding to a computational exception, the
>     behaviour is undefined; otherwise ...
>
> [2] [SUSv4§2.4.3] The behavior of a process is undefined after it
>     returns normally from a signal-catching function for a SIGBUS,
>     SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(),
>     sigqueue(), or raise().

How odd!  I am sure you are right, but I was equally sure I'd seen some
claim that it was OK to return from explicitly raised "computational
exceptions" in the C standard.  Oh well, good to know.  Thanks.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24100

On 08/01/2012 04:47 PM, hip cat wrote:
> On Wed, 01 Aug 2012 15:33:20 -0400, James Kuyper wrote:
...
>> Well, as "Nobody" has already pointed out, that's not an option. Using
>> SIG_IGN for this has undefined behavior. So does registering your own
>> SIGSEGV "handler" that doesn't bother to actually do anything, and
>> simply returns. Therefore, you're going to have to either insert the
>> null checks, or let the program abort() - your choice.
> 
> Word Jim,
> 
> I think Eric was right on the money asking about the return value. If the 
> signal() call returns success, but the "ignore" is ignored, I say that's 
> a bug in the C library. I think I'll file a bug report against glibc.

The C standard specifies that dereferencing a null pointer  has
undefined behavior. One of the possibilities allowed by that fact is
that a SIGSEGV signal is raised, but the standard does not require that
it be raised. Whether or not that signal is raised, and regardless of
whether the SIGSEGV handler has been set to SIG_IGN, SIG_DFL, or an
actual signal handler, the behavior of your program remains undefined by
the C standard. It doesn't matter what the signal handler actually does,
the behavior of your program became undefined as soon as it dereferenced
a null pointer.

The POSIX standard does specify that a SIGSEGV signal be raised, but
specifies that the behavior of your program is undefined if that signal
is ignored, or if the signal handler returns.

"undefined behavior" means that anything is permitted, including
aborting your program. Your program aborted, which is one of the
permitted behaviors. On what grounds are you going to report a bug? What
requirement of any standard is violated by the fact that your program
aborted?

[toc] | [prev] | [next] | [standalone]

#24101

On 08/01/2012 04:47 PM, hip cat wrote:
> On Wed, 01 Aug 2012 15:33:20 -0400, James Kuyper wrote:
...
>> Well, as "Nobody" has already pointed out, that's not an option. Using
>> SIG_IGN for this has undefined behavior. So does registering your own
>> SIGSEGV "handler" that doesn't bother to actually do anything, and
>> simply returns. Therefore, you're going to have to either insert the
>> null checks, or let the program abort() - your choice.
> 
> Word Jim,
> 
> I think Eric was right on the money asking about the return value. If the 
> signal() call returns success, but the "ignore" is ignored, I say that's 
> a bug in the C library. I think I'll file a bug report against glibc.

The C standard specifies that dereferencing a null pointer  has
undefined behavior. One of the possibilities allowed by that fact is
that a SIGSEGV signal is raised, but the standard does not require that
it be raised. Whether or not that signal is raised, and regardless of
whether the SIGSEGV handler has been set to SIG_IGN, SIG_DFL, or an
actual signal handler, the behavior of your program remains undefined by
the C standard. It doesn't matter what the signal handler actually does,
the behavior of your program became undefined as soon as it dereferenced
a null pointer.

The POSIX standard does specify that a SIGSEGV signal be raised, but
specifies that the behavior of your program is undefined if that signal
is ignored, or if the signal handler returns.

"undefined behavior" means that anything is permitted, including
aborting your program. Your program aborted, which is one of the
permitted behaviors. On what grounds are you going to report a bug? What
requirement of any standard is violated by the fact that your program
aborted?

[toc] | [prev] | [next] | [standalone]

#24124

On Wed, 01 Aug 2012 20:47:17 +0000, hip cat wrote:

> I think Eric was right on the money asking about the return value. If the
> signal() call returns success, but the "ignore" is ignored, I say that's a
> bug in the C library. I think I'll file a bug report against glibc.

It's not a bug in glibc. You tell it to ignore SIGSEGV, it ignores
SIGSEGV. According to POSIX, ignoring a synchronous[1] SIGSEGV results in
undefined behaviour, which could mean anything, including raising SIGSEGV.

[1] One generated by an invalid memory access. A SIGSEGV generated by
kill(), sigqueue() or raise() *can* be ignored, hence it would be a bug if
glibc reported an error for signal(SIGSEGV, SIG_IGN).

Note that it *is* an error (§2.4.3) to set the action for SIGKILL or
SIGSTOP to SIG_IGN:

	The system shall not allow the action for the signals SIGKILL or SIGSTOP
	to be set to SIG_IGN.

[toc] | [prev] | [next] | [standalone]

#24088

On 2012-08-01, hip cat <nospam@nospam.com> wrote:
>
> My code has a certain pointer that sometimes unexpectedly becomes null. 
> It would be a lot of work to find every place the pointer gets 
> dereferenced and add a null check. So I want to just ignore it by 
> catching the signal.

And you expect the program will work correctly and produce meaningful
output if you ignore what is normally a very fatal error condition?

I do hope you're not writing code that will be used in any important
production environment.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#24093

On 8/1/2012 2:58 PM, hip cat wrote:
> On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
>> In article <jv9e9e$bj3$1@speranza.aioe.org>, hip cat
>> <nospam@nospam.com> wrote:
>>> What up

I wasn't aware that we had a choice of "up".  I think I'll take that "up" 
over there...

>>> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>>> a null pointer my program still crashes out with segfault SIGSEGV. What
>>> gives?
>>
>> I am amused and curious -- what did you *want* to happen on a null
>> pointer dereference?
>
> Word Ed,

Yes, "Ed" is a word.  More specifically, a proper noun.

> My code has a certain pointer that sometimes unexpectedly becomes null.

Then use a debugger to trap when the pointer "unexpectedly becomes 
null(sic)".  If the pointer changes without you changing it, find that bug 
and fix it.  Don't simply say "that's okay, I'll just ignore NULL pointers 
and pretend they don't exist.

> It would be a lot of work to find every place the pointer gets
> dereferenced and add a null check.

Why not put a check at the top, and handle it, rather than pretending 
everything is okay?

> So I want to just ignore it by
> catching the signal.

So, what should this do?

     char *pt = NULL;
     char c = *pt;

What value should be in c?

Besides, you're not "catching" the signal.  Instead, you're telling the 
system to ignore that signal, which as others have pointed out, is UB for 
SIGSEGV.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web