www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/02/04/10:29:49

Date: Wed, 4 Feb 1998 17:25:13 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
cc: eldredge AT ap DOT net, djgpp-workers AT delorie DOT com
Subject: Re: NSIG ?
In-Reply-To: <199802031340.IAA28128@delorie.com>
Message-ID: <Pine.SUN.3.91.980204171714.26317B-100000@is>
MIME-Version: 1.0

On Tue, 3 Feb 1998, DJ Delorie wrote:

> This is tricky, since arrays are not pointers you'd have to have two
> complete arrays (one for each name) to prevent namespace pollution.  I
> had to do this for the error list (what perror/strerror uses).

Yeah, I figured this would be the problem.  It's hardly worth the hassle 
to have two identical arrays, I think.  The question is, which one is 
more popular?  To me it seemed that the version without the leading 
underscore is.

Is the _sys_siglist[] variety found on SysV Unices?  What does SGI use?  
At least Sun/Solaris here has sys_siglist, but that might be for 
compatibility with SunOS 4.x which is BSD.

> You can cast a string *to* const, but it's harder to cast it away from
> const.

The problem is that if I say ``char *foo = "foobar";'', GCC treats foo 
as const char *, and then complains when I say ``sys_siglist[i] = foo;'' 
because sys_siglist is char [], not const char [].  I couldn't find an 
easy way out of this, and I didn't want to use unconst since it is not 
really needed here.

> The other problem is that programs not expecting the const may not
> compile if they use non-const-char-* pointers to hold the values from
> _sys_siglist[].

That was the other reason I decided not to worry about this.  Both Emacs 
and Make (two programs that use sys_siglist[]) declare it as non-const.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019