[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] updates, etc.
From: |
David Lawrence Ramsey |
Subject: |
Re: [Nano-devel] updates, etc. |
Date: |
Mon, 21 Jun 2004 21:32:03 +0200 |
User-agent: |
Mutt/1.5.6+20040523i |
--- Chris Allegretta <address@hidden> wrote:
>On Mon, May 31, 2004 at 02:51:03PM -0400, David L. Ramsey wrote:
>> 5. Deal with the inability to build nano CVS if glib isn't installed
>> even if we don't need to use glib's v?snprintf(). When v?snprintf()
>> isn't available, glib 2.4.x has moved to using v?asnprintf() from
>> gnulib CVS and providing its own wrappers around those functions to
>> implement all the printf functions. We could do the same with the
>> files from gnulib and borrow just the wrappers for v?snprintf() (and
>> possibly the tests for C99-compliant v?snprintf()) from glib, so that
>> all of glib doesn't have to be installed to get the v?snprintf()
>> functions on systems that lack them. Thoughts?
>
>Not a bad idea, that's originally why we bundled gettext() of course.
>Glib is still far from commonly available on non-free OSes. How much
>extra code would that be, one source file?
Actually, several:
* acinclude.m4: from glib, the macro to test for C99 vsnprintf()
* possibly a few other m4 files needed in order for configure to check
for certain needed capabilities (at least some of which we probably
already have)
* asnprintf.c: asnprintf(), mostly a wrapper for vasnprintf()
* printf-args.[ch]: argument reading functions
* printf-parse.[ch]: argument parsing functions
* printf.[ch]: from glib, the v?snprintf() wrappers for v?asnprintf()
* vasnprintf.[ch]: vasnprintf(), where the real work is done
* xsize.h: small functions to avoid overflows
We could just follow the glib route and add a gnulib directory
containing the files and only compile them if necessary. Or, when nano
is converted to handle UTF-8 (and hence wchar_t*'s instead of char*'s),
we could just use the wide-character version of it, swprintf(), which is
apparently in ANSI.
>> 6. mkstemp() is only available under BSD 4.3 and POSIX 1003.1-2001.
>> There should be an included version of it for systems that don't have
>> it.
>
>Were people running into build problems on any particular OS as a
>result of this?
Not that I'd heard of yet, but I was just concerned that if we have
systems that don't follow the C standard as of 1999 for snprintf() and
the like, those systems probably don't follow the POSIX standard as of
2001 either. If they were BSD-derived, they'll probably have it, but
that can't be guaranteed. I'm just paranoid, I guess.
I've looked into it further and, according to gnulib's included modules
list, chown(), lstat(), regex matching, and utime() are also in
POSIX:2001 among other standards, so I take my previous comment back;
having to write equivalents for them all is basically insane. (Besides,
what really decent UNIX-like system doesn't have a chown() function?)
If the lack of one of these functions turns out to be a problem on some
systems, we could just use the gnulib versions of those functions too,
but until then, we can probably get away with leaving things as they are
now. It's still (mostly) POSIX, after all.
>At some point we have to rely on *some* level of POSIX in order to
>write programs :)
Which is why I'm not trying to support the *really* ancient systems that
don't even follow POSIX.1 (or ANSI C89, for that matter), or that use
TIOCGSIZE instead of TIOCGWINSZ to do window resizes.
Wasn't there someone who said "The nice thing about standards is that
there are so many to choose from?" :)