Re: [Nano-devel] updates, etc.

[David Lawrence Ramsey]

--- 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?" :)