Skip to Content.
Sympa Menu

freetds - RE: asprintf vasprintf

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Bernd Jendrissek <berndj AT prism.co.za>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: RE: asprintf vasprintf
  • Date: Thu, 29 Aug 2002 18:25:19 +0200


On Thu, Aug 29, 2002 at 11:03:23AM -0400, Castellano, Nicholas wrote:
> The real problem is like this. Say you have some other thread that does
> something really bad, generating a SIGSEGV. It just so happens that your
> luck is bad, and at the time that the SIGSEGV was generated, vasprintf() has
> installed its sigsegv() function to handle this signal.
>
> Now, this other thread has entered sigsegv(). Even if it can determine
> "Gee, I really don't belong here, this handler is really here to service the
> thread doing the asprintf()!", what can you do about it at that point?
> Maybe we want to dump core at this point. But maybe there's another SIGSEGV
> handler, temporarily replaced by the one in asprintf.c, and if we could only
> figure out what that handler was, we could call it to get the correct
> behavior.

I don't understand why all this talk about SIGSEGV handlers. From man 2
sigaction:

According to POSIX, the behaviour of a process is unde­
fined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal
that was not generated by the kill() or the raise() func­
tions. Integer division by zero has undefined result. On
some architectures it will generate a SIGFPE signal.
(Also dividing the most negative integer by -1 may gener­
ate SIGFPE.) Ignoring this signal might lead to an end­
less loop.

Anything depending on handling SIGSEGV will be platform-dependent anyway.

--
berndfoobar AT users.sourceforge.net is probably better to bookmark than any
employer-specific email address I may have appearing in the headers.
Vanity page: http://www.tsct.co.za/~berndj/




Archive powered by MHonArc 2.6.24.

Top of Page