Re: [Gcl-devel] gcl_signal

[Camm Maguire]

Greetings!

Michael Koehne <address@hidden> writes:

> Moin Mike Thomas,
> 
> > As a last minute thought before 2.6.2 marches out the door, what do you
> > think of these items?
> > 1. in "usig.c"
> >    EXTER char signals_handled[6];
> 
>   *hm* the EXTER is confusing to the programmer, because EXTER in a
>   include file means to have it extern, and allocated by main.c !
>   So :
> 
>       extern char signals_handled[];
> 
> > #define OTHER_SIGNALS_HANDLED SIGTERM,SIGKILL,SIGABRT,
> > char signals_handled [] = {SIGINT,SIGUSR2,SIGUSR1,SIGIO,SIGALRM,
> > #ifdef OTHER_SIGNALS_HANDLED
> >                        OTHER_SIGNALS_HANDLED
> > #endif
> >                        0};
> 
>   allocation by compiler should be fine in this way, as no later
>   signals are added.
> 

Just a note here that I agree with Michael.  His description below is
also correct to my understanding.  In general, we should avoid
duplicating hard-coded constants in situations like this.  Likewise,
the EXTER macro is meant for situations in which the same line can be
used to allocate the space in one file, and provide an extern
declaration in another, which is obviously not applicable here.

In 2.7.0, we need to think about cleaning things up to retain out
sanity.  I'll try to post some suggested guidelines for discussion
purposes.  One idea that comes immediately to the fore is to separate
out platform specific code in well defined and isolated regions,
e.g. the .h files, i.e. as opposed to having many ifdefs in the main
source files.  Likewise, we need to hopefully autogenerate all the
info in the .h via configure.

> > (that is, SIGUSR2 (inserted in signals_handled) is not installed, but
> > SIGPIPE and SIGFPE (not present in the signals_handled vector) are at least
> > passed into the function even if not dealt with.)
> > 5. in "main.c" install_segmentation_catcher also runs gcl_signal on SIGSEGV,
> > which is, also, not present in the signals_handled vector.
> 
>   this might be on purpose, as signals in signals_handled are handled
>   by main_signal_handler first, who knows what to do on each of them,
>   and then delegated to the user installed handler, while those other
>   signals are dealt by the user defined signal handler directly. There
>   wont be any need for this signals_handled array, if it includes every
>   possible signal.

Agreed.  If time allows, I'll try to look at this more carefully to
glean what the original intention might have been in separating out
these particular signals.

Take care,

> 
> Bye Michael
> -- 
>   mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
>   http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah