Xref: csiph.com comp.arch:6253 Newsgroups: comp.arch Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!kithrup.com!mrs From: mrs@kithrup.com (Mike Stump) Subject: Re: M68k add to memory is not a mistake any more Message-ID: Date: Mon, 5 Mar 2012 08:46:47 GMT References: <23c57d6f-9b53-4336-9ec6-4b9d1a401f91@t16g2000yqt.googlegroups.com> <65t3r.2733$HX7.1008@newsfe11.iad> Organization: Kithrup Enteprises, Ltd. X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Lines: 35 In article , wrote: >In article <65t3r.2733$HX7.1008@newsfe11.iad>, >However, none of the above is the point. There is no defined >mechanism for a C program to receive an interrupt and execute any >code. Sure there is... You can compile it with a C++ compiler: A POF that could be used as a signal handler in a conforming C program does not produce undefined behavior when used as a signal handler in a C++ program. In C++, there are a multitude of perfectly defined uses that one can use. Further, even in C, you can set a sig_atomic_t and then in another thread, notice that, _and_ call runtime routines, or do anything else you want. There is absolutely no restriction or limitation relating to signals on that other thread. Now, you say, thread, what's that, which not in the C standard, it is a way to program in C, using a different standard, POSIX and use threads. The nice thing about standards is, there are so many to choose from. Instead of stopping at the ANSI definition for C, very few people stop there anymore, consider POSIX or some other standard that does offer more. Next, on real systems, one can write perfectly portable code, no matter the C standard. Linux, for example, is one such system. In the end, it isn't Standards that matter, it is portability that matters. >Despite appearances, there is no path through C's signal restrictions >that does not result in undefined behaviour! I have heard that Ada >does allow that, but I know of no other standard or portable language >that does. We can only point you to the C++ Standard, the rest, you have to do. :-)