Re: Non-standard types in public header files

Stepan Kasal <[EMAIL PROTECTED]> writes: > Hello, > > this mail is a lengthy story "to the most abstract solution and back > to the basic one". Sorry, I couldn't have helped. > >> The problem, of course, is that the installed header file cannot >> assume a config.h and the HAVE_* stuff. > > Indee

Re: Non-standard types in public header files

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> I realized I couldn't use the ssize_t module directly in GnuTLS. >> GnuTLS uses ssize_t in its public header file > > Ouch. This is as bad as using 'bool' in public header files. They are used for function types that are suppose

Re: [bug-gnulib] Non-standard types in public header files (was: Re: ssize_t)

Simon Josefsson wrote: > I realized I couldn't use the ssize_t module directly in GnuTLS. > GnuTLS uses ssize_t in its public header file Ouch. This is as bad as using 'bool' in public header files. > The problem, of course, is that the installed header file cannot > assume a config.h and the HAV

Re: ssize_t

dnl Copyright (C) 2001-2003 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. What do we call this?

Re: isascii

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> isascii is not part of C89, but POSIX: >> >> http://www.opengroup.org/onlinepubs/009695399/functions/isascii.html > > Do you know about a system that doesn't have it? No. I added it because a workaround for missing isascii was

Re: Non-standard types in public header files (was: Re: ssize_t)

Hello, this mail is a lengthy story "to the most abstract solution and back to the basic one". Sorry, I couldn't have helped. > The problem, of course, is that the installed header file cannot > assume a config.h and the HAVE_* stuff. Indeed, this is the root of the problem. You try to find a

Re: [bug-gnulib] Re: Opening a can of worms: a readline gnulib module?

Oskar Liljeblad wrote: > That's why you have xyz_LTLIBS, xyz_CFLAGS etc. One such example is > PTHREAD_CFLAGS, would you prefer that or CFLAGSPTHREADS? I would > prefer the former. HAVE_READLINE vs. READLINE_LIBS is just inconsistent. Either READLINE_PRESENT and READLINE_LIBS. Or HAVE_READLINE and

Re: [bug-gnulib] isascii

Simon Josefsson wrote: > isascii is not part of C89, but POSIX: > > http://www.opengroup.org/onlinepubs/009695399/functions/isascii.html Do you know about a system that doesn't have it? What about using c_isascii from the c-ctype module? Bruno ___ b

Non-standard types in public header files (was: Re: ssize_t)

I realized I couldn't use the ssize_t module directly in GnuTLS. GnuTLS uses ssize_t in its public header file, so it has this in configure.ac: AC_CHECK_TYPE(ssize_t, DEFINE_SSIZE_T="#include " AC_SUBST(DEFINE_SSIZE_T) , AC_DEFINE(NO_SSIZE_T, 1, [no ssize_t type was found]) DEFINE_SSIZE_T="typedef

Re: ssize_t

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> GnuTLS need ssize_t, but there is no module for it right now. How >> about the patch below? > > Looks OK to me. Installed. I wrote LGPL as the license. Thanks! ___ bug-gnulib mail

Re: Opening a can of worms: a readline gnulib module?

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> I installed the patch below. It builds on the same platforms, but now >> finds the readline library properly on Fedora too. >> ... >> checking for readline... yes >> checking how to link with libreadline... -lreadline -ltermcap

Re: [bug-gnulib] Re: Opening a can of worms: a readline gnulib module?

On Friday, August 12, 2005 at 13:42, Bruno Haible wrote: > > I'll check the code soon, but why don't you use READLINE_LIBS instead > > of LIBREADLINE etc? That's the convention most other automake macros > > I've seen use. > > But this convention doesn't cope with the fact that link options for li

Re: ssize_t

Simon Josefsson wrote: > GnuTLS need ssize_t, but there is no module for it right now. How > about the patch below? Looks OK to me. > I'm not sure what the License field for ssize_t.m4 should be. The M4 > file says: > > dnl Copyright (C) 2001-2003 Free Software Foundation, Inc. > dnl This file

Re: Opening a can of worms: a readline gnulib module?

Simon Josefsson wrote: > I installed the patch below. It builds on the same platforms, but now > finds the readline library properly on Fedora too. > ... > checking for readline... yes > checking how to link with libreadline... -lreadline -ltermcap This is a problem because libtermcap is unsecure

Re: [bug-gnulib] Re: Opening a can of worms: a readline gnulib module?

Oskar Liljeblad wrote: > I'll check the code soon, but why don't you use READLINE_LIBS instead > of LIBREADLINE etc? That's the convention most other automake macros > I've seen use. But this convention doesn't cope with the fact that link options for libtool may be different than link options for

isascii

isascii is not part of C89, but POSIX: http://www.opengroup.org/onlinepubs/009695399/functions/isascii.html GnuTLS uses it. How about the patch below? Index: ChangeLog === RCS file: /cvsroot/gnulib/gnulib/ChangeLog,v retrieving rev

ssize_t

Hello! GnuTLS need ssize_t, but there is no module for it right now. How about the patch below? I'm not sure what the License field for ssize_t.m4 should be. The M4 file says: dnl Copyright (C) 2001-2003 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundatio

Re: Opening a can of worms: a readline gnulib module?

Simon Josefsson <[EMAIL PROTECTED]> writes: >> Also check this: >> >> http://ac-archive.sourceforge.net/Installed_Packages/vl_lib_readline.html >> >> It also mentions libedit and libeditline (apparently those are other >> GNU readline-like implementations). > > That seem like a quite useful macro,