🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.lang.c
Article #267803

Re: Ciemna strona C++

#267803
From: Maciej Sobczak
Date: Wed, 05 Dec 2007 14:14
61 lines
4413 bytes
On 5 Gru, 14:44, Sektor van Skijlen
<ethou...@guess.if.gmail.com.is.valid.or.invalid> wrote:

> > Funkcje podane przez użytkownika są ZAMIAST a nie PRZED.
> > set_terminate() ustawia funkcję, wobec której standard wymaga, aby
> > zakończyła program. Nie ma sensu rozważać, co się dzieje potem.
>
> Gdzie tak przepraszam wyczytałeś, bo ja niczego takiego w standardzie nie
> widzę

Przecież sam zacytowałeś:

> typedef void (* unexpected_handler )();
[...]
> 2 Required behavior: An unexpected_handler shall not return. See also 15.5.2.
[...]
> typedef void (* terminate_handler )();
[...]
> 2 Required behavior: A terminate_handler shall terminate execution of the
> program without returning to the
> caller.

Zwróć uwagę na shall powyżej, w obu przypadkach.

> Czy na podstawie standardu jesteś więc w stanie określić, czy:
>  - wolno nie kończyć programu w terminate()

Nie wolno.

>  - implementacji wolno utłuc program abort()-em jeśli użytkownik nie ubije
>    wcześniej programu w swoim handlerze terminate()?

Wolno. Skoro użytkownik *nie spełnił wymagań* nałożonych przez
standard na jego handler, to skazuje program na UB. Implementacja może
swobodnie utłuc taki program.

> Nie przyglądałem się, jak to jest w standardzie - o tym, że oryginalna
> terminate() i tak jest wołana po funkcji użytkownika, przeczytałem w DEC++.

W takim razie jest to informacja na temat DEC++.

> Nie wiem, na ile jest to sprawa implementacji, ale jedynym sposobem wymuszenia
> na użytkowniku, żeby w swoim handlerze spowodował zakończenie programu jest
> spowodowanie zakończenia programu po jej zakończeniu. Ponieważ w domyślnej
> sytuacji nic innego nie robi (a kończy program i tak w ten sam sposób), więc
> metodą logicznej eliminacji jedyną sensowną implementacją spełniającą wymogi
> standardu jest wywołać abort() zaraz po wykonaniu funkcji użytkownika -
> najwyżej użytkownik zakończy program poprzez exit() zanim do tego dojdzie.

Nie widzę takiego wymagania, nawet jeśli sam bym tak to
zaimplementował.

> Ale nawet zakładając, że tak rzecze standard, nie zmienia to faktu: większość
> tutoriali twierdzi stanowczo, że funkcja ta używana jest ZAMIAST oryginalnego
> handlera, "trochę zapominając" wspomnieć, że funkcja ta MUSI spowodować
> również zakończenie programu.

Widocznie te tutoriale nie są tak dokładne jak standard.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Technical Details
Message-ID: <240a4947-994a-4b71-8aab-358ad88da5a9@e25g2000prg.googlegroups.com>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!news.internetia.pl!news.nask.pl!news.nask.org.pl!news.germany.com!postnews.google.com!e25g2000prg.googlegroups.com!not-for-mail
References: <fghgeo$spf$1@nemesis.news.tpi.pl> <fh1tjd$dtt$1@bozon2.softax.pl> <fh2lj6$qkh$1@news.vectranet.pl> <fha3as$pap$1@bozon2.softax.pl> <fhaj8u$e02$1@news.vectranet.pl> <fhf09d$ohq$1@bozon2.softax.pl> <fhfi9l$640$1@news.vectranet.pl> <fhurmu$5d9$1@bozon2.softax.pl> <fhv020$8k1$1@news.vectranet.pl> <fi1bs4$nn3$1@bozon2.softax.pl> <fi27ds$gt1$1@kujawiak.man.lodz.pl> <1195688300.8426.30.camel@qrnik> <fi3ems$7ig$1@kujawiak.man.lodz.pl> <1195734091.8426.77.camel@qrnik> <fi6n5f$fpr$1@kujawiak.man.lodz.pl> <1195858230.20523.107.camel@qrnik> <fie2un$cbn$1@kujawiak.man.lodz.pl> <1196076390.30869.52.camel@qrnik> <fj1tmo$52u$1@kujawiak.man.lodz.pl> <1101d6ea-b312-4214-b153-8e1cc26a99ba@n20g2000hsh.googlegroups.com> <fj69vc$te$1@kujawiak.man.lodz.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!news.internetia.pl!news.nask.pl!news.nask.org.pl!news.germany.com!postnews.google.com!e25g2000prg.googlegroups.com!not-for-mail
From: Maciej Sobczak <see.my.homepage@gmail.com>
Newsgroups: pl.comp.lang.c
Subject: Re: Ciemna strona C++
Date: Wed, 5 Dec 2007 06:14:03 -0800 (PST)
Organization: http://groups.google.com
Lines: 77
Message-ID: <240a4947-994a-4b71-8aab-358ad88da5a9@e25g2000prg.googlegroups.com>
References: <fghgeo$spf$1@nemesis.news.tpi.pl> <fh1tjd$dtt$1@bozon2.softax.pl>  <fh2lj6$qkh$1@news.vectranet.pl> <fha3as$pap$1@bozon2.softax.pl>  <fhaj8u$e02$1@news.vectranet.pl> <fhf09d$ohq$1@bozon2.softax.pl>  <fhfi9l$640$1@news.vectranet.pl> <fhurmu$5d9$1@bozon2.softax.pl>  <fhv020$8k1$1@news.vectranet.pl> <fi1bs4$nn3$1@bozon2.softax.pl>  <fi27ds$gt1$1@kujawiak.man.lodz.pl> <1195688300.8426.30.camel@qrnik>  <fi3ems$7ig$1@kujawiak.man.lodz.pl> <1195734091.8426.77.camel@qrnik>  <fi6n5f$fpr$1@kujawiak.man.lodz.pl> <1195858230.20523.107.camel@qrnik>  <fie2un$cbn$1@kujawiak.man.lodz.pl> <1196076390.30869.52.camel@qrnik>  <fj1tmo$52u$1@kujawiak.man.lodz.pl> <1101d6ea-b312-4214-b153-8e1cc26a99ba@n20g2000hsh.googlegroups.com>  <fj69vc$te$1@kujawiak.man.lodz.pl>
NNTP-Posting-Host: 128.141.44.124
Mime-Version: 1.0
X-Trace: posting.google.com 1196864043 29958 127.0.0.1 (5 Dec 2007 14:14:03 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 5 Dec 2007 14:14:03 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: e25g2000prg.googlegroups.com; posting-host=128.141.44.124;  posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US;  rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9,gzip(gfe),gzip(gfe)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit