On 06/13/13 12:32, Daniel J Sebald wrote:
derived from the attached files?
That's pretty nice Bruce. Please explain how this will be used
in the build process, just so I understand.
Not all users of gnulib necessarily have code generation tools,
so the generated file needs to get checked int
On 06/13/2013 09:37 AM, Bruce Korb wrote:
On 06/10/13 22:41, Paul Eggert wrote:
Maybe someone else can come up with something even better.
This:
#define SIG_OFFSET_AFTER_START 0
static char const sig_strings[] =
#ifdef SIGHUP
#define SIG_HUP_OFFSET SIG_OFFSET_AFTER_START
#define SIG_OFFSET_
On 06/10/13 22:41, Paul Eggert wrote:
Maybe someone else can come up with something even better.
This:
#define SIG_OFFSET_AFTER_START 0
static char const sig_strings[] =
#ifdef SIGHUP
#define SIG_HUP_OFFSET SIG_OFFSET_AFTER_START
#define SIG_OFFSET_AFTER_HUP (SIG_OFFSET_AFTER_START + 4)
"H
On 06/10/2013 07:50 PM, Daniel J Sebald wrote:
> char sig_strings[] = {
> #ifdef SIGHUP
> HUP_STRING, '\0',
> #endif
Yes, that's better, though it should look more like this:
char const sig_strings[] =
#define HUP_OFFSET 0
#ifdef SIGHUP
"HUP" "\0"
# define INT_OFFSET (HUP_OFFSET + sizeof "HUP
On 06/10/2013 09:36 PM, Daniel J Sebald wrote:
On 06/10/2013 05:47 PM, Paul Eggert wrote:
On 06/05/13 09:57, Daniel J Sebald wrote:
Well, taking this all into consideration, perhaps the easiest thing
to do is construct a table at runtime on the heap:
I'd rather avoid the runtime overhead.
On 06/10/2013 05:47 PM, Paul Eggert wrote:
On 06/05/13 09:57, Daniel J Sebald wrote:
Well, taking this all into consideration, perhaps the easiest thing to do is
construct a table at runtime on the heap:
I'd rather avoid the runtime overhead.
How about something like this?
enum { HUP_OFFS
On 06/05/13 09:57, Daniel J Sebald wrote:
>
>
> Well, taking this all into consideration, perhaps the easiest thing to do is
> construct a table at runtime on the heap:
I'd rather avoid the runtime overhead.
How about something like this?
enum { HUP_OFFSET = 0 };
#define HUP_STRING "string fo
On 06/05/2013 02:17 AM, Thien-Thi Nguyen wrote:
() Daniel J Sebald
() Tue, 04 Jun 2013 12:35:00 -0500
> I seem to recall a paper several years back that argued against
> this approach based on ldso issues. Drat, can't dredge the
> details...
I tried searching the Internet fo
On 06/04/2013 12:35 PM, Daniel J Sebald wrote:
On 06/04/2013 02:47 AM, Thien-Thi Nguyen wrote:
() Paul Eggert
() Mon, 03 Jun 2013 15:28:24 -0700
extern char const allsigstr[];
This would consist of a concatenation of null-terminated strings,
one per name, terminated by an empty string.
[compi
() Daniel J Sebald
() Tue, 04 Jun 2013 12:35:00 -0500
> I seem to recall a paper several years back that argued against
> this approach based on ldso issues. Drat, can't dredge the
> details...
I tried searching the Internet for such issues, but couldn't find
any. What do you rec
On 06/04/2013 02:47 AM, Thien-Thi Nguyen wrote:
() Paul Eggert
() Mon, 03 Jun 2013 15:28:24 -0700
extern char const allsigstr[];
This would consist of a concatenation of null-terminated strings,
one per name, terminated by an empty string.
[compile time wins]
I seem to recall
() Paul Eggert
() Mon, 03 Jun 2013 15:28:24 -0700
extern char const allsigstr[];
This would consist of a concatenation of null-terminated strings,
one per name, terminated by an empty string.
[compile time wins]
I seem to recall a paper several years back that argued against this
a
On 06/03/2013 05:28 PM, Paul Eggert wrote:
How about the following idea instead?
Have sig2str.h export an array like this:
extern char const allsigstr[];
This would consist of a concatenation of null-terminated strings,
one per name, terminated by an empty string.
allsigstr could be initialize
How about the following idea instead?
Have sig2str.h export an array like this:
extern char const allsigstr[];
This would consist of a concatenation of null-terminated strings,
one per name, terminated by an empty string.
allsigstr could be initialized at compile-time, with no runtime
actions ne
On 06/02/2013 01:57 PM, Paul Eggert wrote:
On 06/01/2013 08:14 PM, Daniel J Sebald wrote:
Please consider placing extern "C" around the sig2str and str2sig declarations
inside sig2str.h similar to the attached diff/changeset. We're looking at using the
sig2str routine in Octave and removing s
On 06/01/2013 08:14 PM, Daniel J Sebald wrote:
> Please consider placing extern "C" around the sig2str and str2sig
> declarations inside sig2str.h similar to the attached diff/changeset. We're
> looking at using the sig2str routine in Octave and removing some code from
> that project that is si
16 matches
Mail list logo
