Re: use of program_name

[Dave Love]

Paul Eggert <[EMAIL PROTECTED]> writes:

> Under the current approach, it's the caller's responsibility to arrange
> for a program_name variable that works, either by using the progname
> module, or by rolling their own program_name variable.

So gnulib shouldn't be used for libraries (or at least not unless you
avoid modules calling `error' or accept errors spewing junk messages)?

> I suppose it might make sense for error.c to avoid using program_name
> if it's null.

That's probably a good idea, but why can't it be initialized to null
in error.c?  (If the interface to it was just set_program_name, it
could be private.)

[Sorry if I'm being dense.  I came across this a while ago when I
couldn't pursue it, and I may have lost some of the context, but I'm
fairly sure it will confuse others.]


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: error compiling regex gnulib module with pgcc compiler

[Ralf Wildenhues]

Forwarding this to PGI support.  This thread is archived at
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/5059 .

* Paul Eggert wrote on Thu, Dec 29, 2005 at 10:35:24PM CET:
> Claudio Fontana <[EMAIL PROTECTED]> writes:
> 
> >> pgcc -DHAVE_CONFIG_H -I. -I. -I.. -g -c regex.c
> >> PGC-F-0249-#error --  "Add case for new bitset_word
> >> size" (./regex_internal.h: 186)
> >> PGC/x86-64 Linux/x86-64 5.2-1: compilation aborted
> >
> > I do not know whether this is something that should be
> > acted upon, or if the compiler in question is not
> > doing the right thing.
> 
> It sounds like the compiler is buggy, and this should be acted upon.

I think so, too.

> What is the value of ULONG_MAX on that host?  Your user can find out
> by compiling the following little program with "pgcc -g -E":
> 
> #include 
> "ULONG_MAX = " ULONG_MAX

"ULONG_MAX = " ( 9223372036854775807L * 2UL + 1UL )

This is pgcc 6.0-8 64-bit target on x86-64 Linux, but as indicated
above, the issue is present in 5.2-1 as well.

> > Could this be related to 64bit quantities being used
> > in preprocessor constant expressions?
> 
> Yes, possibly the pgcc preprocessor mishandles 64-bit numbers.

Yep.  Here's a small self-contained example to expose the fact that the
preprocessor does not do correct 64bit unsigned arithmetic:

/* snip */
#include 
#include 

#define BITSET_WORD_MAX ULONG_MAX

int main(void)
{
#if BITSET_WORD_MAX >> 31 >> 31 >> 1 == 1
#else
  puts("preprocessor is buggy");
#endif

  printf("ULONG_MAX = %llu\nsizeof(ulong) = %lu\n", ULONG_MAX, sizeof(unsigned 
long));
  printf("%llu\n", BITSET_WORD_MAX >> 31 >> 31 >> 1);
  return 0;
}
/* snip */

It outputs 
| preprocessor is buggy
| ULONG_MAX = 18446744073709551615
| sizeof(ulong) = 8
| 1

Cheers,
Ralf


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: error compiling regex gnulib module with pgcc compiler

[Paul Eggert]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> This is pgcc 6.0-8 64-bit target on x86-64 Linux, but as indicated
> above, the issue is present in 5.2-1 as well.

Thanks for checking that.  Can you please run the following
program on that platform and send us the output?  If it outputs
"preprocessor thinks BITSET_WORD_BITS = 64", then we have an
obvious fix to regex_internal.h.  Thanks.

#include 

/* Maximum value of a bitset word.  It must be useful in preprocessor
   contexts, and must be consistent with bitset_word.  */
#define BITSET_WORD_MAX ULONG_MAX

/* Number of bits in a bitset word.  Avoid greater-than-32-bit
   integers and unconditional shifts by more than 31 bits, as they're
   not portable.  */
#if BITSET_WORD_MAX == 0x
# define BITSET_WORD_BITS 32
#elif BITSET_WORD_MAX >> 31 >> 5 == 1
# define BITSET_WORD_BITS 36
#elif BITSET_WORD_MAX >> 31 >> 16 == 1
# define BITSET_WORD_BITS 48
#elif BITSET_WORD_MAX >> 31 >> 28 == 1
# define BITSET_WORD_BITS 60
#elif BITSET_WORD_MAX >> 31 >> 31 >> 1 == 1
# define BITSET_WORD_BITS 64
#elif BITSET_WORD_MAX >> 31 >> 31 >> 9 == 1
# define BITSET_WORD_BITS 72
#elif BITSET_WORD_MAX >> 31 >> 31 >> 31 >> 31 >> 3 == 1
# define BITSET_WORD_BITS 128
#elif BITSET_WORD_MAX >> 31 >> 31 >> 31 >> 31 >> 31 >> 31 >> 31 >> 31 >> 7 == 1
# define BITSET_WORD_BITS 256
#elif BITSET_WORD_MAX >> 31 >> 31 >> 31 >> 31 >> 31 >> 31 >> 31 >> 31 >> 7 > 1
# define BITSET_WORD_BITS 257 /* any value > SBC_MAX will do here */
# if BITSET_WORD_BITS <= SBC_MAX
#  error "Invalid SBC_MAX"
# endif
#elif BITSET_WORD_MAX == (0x + 2) * 0x
/* Work around a bug in PGC GNU/Linux x86-64 5.2-1 and 6.0-8 (and
   probably other versions), where the preprocessor mishandles large
   unsigned values and thinks they are signed.  */
# define BITSET_WORD_BITS 64
#else
# error "Add case for new bitset_word size"
#endif


#include 

int main(void)
{
  printf("ULONG_MAX = %lu\nsizeof(ulong) = %lu\n", ULONG_MAX,
 (unsigned long) sizeof(unsigned long));
  printf("%lu\n", BITSET_WORD_MAX >> 31 >> 31 >> 1);
  printf("BITSET_WORD_BITS = %d\n", BITSET_WORD_BITS);
#if BITSET_WORD_BITS == 32
  printf("preprocessor thinks BITSET_WORD_BITS = 32\n");
#elif BITSET_WORD_BITS == 64
  printf("preprocessor thinks BITSET_WORD_BITS = 64\n");
#else
  printf("preprocessor has some other value for BITSET_WORD_BITS\n");
#endif
  return 0;
}


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: use of program_name

[Paul Eggert]

Dave Love <[EMAIL PROTECTED]> writes:

> Paul Eggert <[EMAIL PROTECTED]> writes:
>
>> Under the current approach, it's the caller's responsibility to arrange
>> for a program_name variable that works, either by using the progname
>> module, or by rolling their own program_name variable.
>
> So gnulib shouldn't be used for libraries (or at least not unless you
> avoid modules calling `error' or accept errors spewing junk messages)?

It is a problem, yes.  However, it's not quite as bad as that.
The library can arrange for program_name to be initialized
before it is used.

>> I suppose it might make sense for error.c to avoid using program_name
>> if it's null.
>
> That's probably a good idea, but why can't it be initialized to null
> in error.c?

Because the current convention is to put this declaration in the main
program, at the top level:

char *program_name;

Hence the main program has allocated program_name, and has arranged
for it to be initialized to null.  If we put a similar declaration in
error.c, it would cause two different definitions of program_name, and
some non-Unix linkers reject this.  (The C Standard allows them to
reject it.)

> (If the interface to it was just set_program_name, it could be private.)

Yes, that would be a better convention.  This will require revamping
pretty much everybody that uses program_name, but I think it's worth
the pain.  What do others think?


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: use of program_name

[Karl Berry]

If we put a similar declaration in error.c, it would cause two
different definitions of program_name, and some non-Unix linkers
reject this.  (The C Standard allows them to reject it.)

Is it a problem in practice, ie, what are these non-Unix linkers?

How about defining it in error.c with an #ifdef:
#ifdef GNULIB_DO_NOT_DECLARE_PROGRAM_NAME
char *program_name;
#endif

Then programs could define the macro if need be.  Perhaps it could be
autoconfed.

This will require revamping pretty much everybody that uses
program_name, but I think it's worth the pain.  What do others
think?

Sounds like an uphill battle to me.

Are you thinking that set_program_name will set something other than
program_name?  Because of course existing code has to continue to work
... not too clear on how old/new code will mix in this case ...


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: use of program_name

[James Youngman]

On Thu, Jan 05, 2006 at 02:03:27PM -0800, Paul Eggert wrote:
> Because the current convention is to put this declaration in the main
> program, at the top level:
> 
> char *program_name;
> 
> Hence the main program has allocated program_name, and has arranged
> for it to be initialized to null.  If we put a similar declaration in
> error.c, it would cause two different definitions of program_name, and
> some non-Unix linkers reject this.  (The C Standard allows them to
> reject it.)
> 
> > (If the interface to it was just set_program_name, it could be private.)
> 
> Yes, that would be a better convention.  This will require revamping
> pretty much everybody that uses program_name, but I think it's worth
> the pain.  What do others think?

I'm against it, but not because of the extra work.  I don't mind that
since the amount of effort is trivial and I can choose when to do it
(i.e. I can choose when to reimport gnulib).

My problem is that we have changed the interface without making it
impossible for the user to use the new interface wrongly.  I would
prefer an arrangement which results in a compilation or link failure
if the user (i.e. software maintainer) fails to initialise things
properly.  A runtime failure is insufficiently helpful in my opinion.

James.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: use of program_name

[Paul Eggert]

[EMAIL PROTECTED] (Karl Berry) writes:

> Is it a problem in practice, ie, what are these non-Unix linkers?

I've run into it on IBM mainframe platforms.  You can run into it even
with GCC, if you use -fno-common.  Googling a bit reveals that libtool
1.5 uses -fno-common on Mac OS X (why, I don't know; see
).

> This will require revamping pretty much everybody that uses
> program_name, but I think it's worth the pain.  What do others
> think?
>
> Sounds like an uphill battle to me.

The hill shouldn't be steep.  The gnulib tradition is to not worry
about backward-compatibility much, at least for trivial improvements
like this.  The idea is that people can import new gnulib source code
at their convenience.  I realize that at time goes on the hill will
become steeper, but I'd rather keep it as flat as possible if I can.

[EMAIL PROTECTED] (James Youngman) writes:

> I would prefer an arrangement which results in a compilation or link
> failure if the user (i.e. software maintainer) fails to initialise
> things properly.

Perhaps we could change progname.h so that 'program_name' is a
function that returns the program name, instead of being a global
variable.  That should catch mishaps at link-time, if not before.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: use of program_name

[Dave Love]

Paul Eggert <[EMAIL PROTECTED]> writes:

> If we put a similar declaration in
> error.c, it would cause two different definitions of program_name, and
> some non-Unix linkers reject this.  (The C Standard allows them to
> reject it.)

Sorry, I thought Unix linkers actually did reject it, which was part
of my problem, but I don't know why I thought so.

I suppose a library could provide the initialization in a separate
object.  But now that I think about it, polluting the namespace with
things like `error' isn't good news, and I should probably try to use
Heimdal's libroken.  And bizarrely-enough, now that I think of it
again, there was a similar issue there with the equivalent
functionality, but without the same interface/compatibility issue.

I think you can ignore me on this anyway.


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: use of program_name

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Paul Eggert on 1/5/2006 4:06 PM:
> 
>>Is it a problem in practice, ie, what are these non-Unix linkers?
> 
> 
> I've run into it on IBM mainframe platforms.  You can run into it even
> with GCC, if you use -fno-common.  Googling a bit reveals that libtool
> 1.5 uses -fno-common on Mac OS X (why, I don't know; see
> ).

Having public variables in libraries also tends to be problematic in
cygwin and other users of Windows .dlls.  The Libtool mailing list can
attest to the problems of exporting data, and recommends that the best
library interfaces consists solely of functions, not data.  Basically, an
application cannot have a const pointer to a data member exported by the
dll, because the relocation machinery of dlls can't perform the relocation
on const pointers to imported data:

http://lists.gnu.org/archive/html/libtool-patches/2004-09/msg00230.html

Therefore, I would welcome a change to the error module that made
program_name settable by calling a function, rather than by assigning a
global data variable.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDvfhx84KuGfSFAYARAg3yAJ4g8NB6/yZ6ddIyEKdk3MrCc2RafACggUE8
w+2RaLVacuSskZWKvgEZAYI=
=xUWn
-END PGP SIGNATURE-


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib