According to Jim Meyering on 12/4/2006 2:21 AM: Is this archive now up-to-date, or is there some issue still holding back the conversion process? The more I have used git over the past few weeks, the
So far, no one has objected to my proposal to convert gnulib development from cvs to git. If there are any nay-sayers, it's time to speak up. I've just gone through the conversion process once more,
Hi Bruno, * Bruno Haible wrote on Mon, May 22, 2006 at 02:13:52PM CEST: Hmm, I think I'm not the right person to judge this, but I do think putting it in the Autoconf manual is a great idea. I'm easi
I just looked at the first couple of errors: In file included from regex.c:85: regex_internal.c: In function `reg_errcode_t re_string_construct(re_string_t*, c onst char*, int, char*, int, const re_
Odd; I don't get those warnings with gcc 4.0.0 -O -Wall: $ gcc -DHAVE_CONFIG_H -I. -I.. -O -Wall -c mktime.c $ gcc --version | sed 1q gcc (GCC) 4.0.0 Anyway, I installed this patch into coreutils. Ca
That is not a strong argument for preferring ssize_t to ptrdiff_t, since we have the same problem with ssize_t. There is no guarantee that ssize_t is the same width as size_t either. ssize_t is a POS
'uc' means a Unicode code position (a.k.a. as "Unicode character"). I have it typedefed in the libunistring package which is under development. Until it is ready for release, I wish to keep linebreak
But the code is not subtle. It's unlikely to be rewritten in the way that you describe; I have never seen the kind of error that you're worrying about. Conversely, I have seen errors masked by casts.
But I don't think C23 has the conversion macros: /* big endian 32 to host. */ uint32_t be32toh (uint32_t); /* little endian 32 to host. */ uint32_t le32toh (uint32_t); Yes, those might be a good reas
Hi Bruno, Yes, I've seen both in gnulib. I'm pretty sure the cast is required for C++ (though I think gcc has a warning to make it less strict). Maybe a 5th category is code taken from another GNU pr
Hi Collin, Different warning policies need to apply in these fours sets code: 1) Code that originates in the package that uses gnulib. Example: coreutils/src/* 2) Code from public header files in gnu
Sounds good. Yeah, there are many things I dislike about that class. I'll probably have a look at *slowly* cleaning it up eventually. There is a bunch of dead code in there if I remember correctly. G
Hi Collin, Thanks! OK to push in 1 or 2 days. I agree that this kind of doing side effects on a GLConfig object that is already held by another object is not super maintainable. However, this is not
Adjust for C programs compiled by GCC 14. (A C++ expert still needs to look at manywarnings-c++.m4.) * build-aux/gcc-warning.spec: Add warnings introduced in GCC 13. * m4/manywarnings.m4 (gl_MANYWARN
Many packages work around this by doing '#undef DATADIR' somewhere [1]. Thanks very much for the pointer, I was able to copy this workaround. It seems that the comment at that reference understates
Yes, I don't see anything that can be done about that sadly. I just want to make it clear that the malicious code was contained in the *additions* that they made to this file: $ diff -u $GNULIB_REFDI
Hi Collin, Common Lisp, in this situation, silently discard the '3' value. The way Python does it helps find signature changes of functions. I agree. Let's keep list(...) only for a data conversion o
Hi Collin, Nice! Thanks, applied. You don't need this trick here, since we sort this part of the list anyway, for compatibility with gnulib-tool.sh. This occurred also with the EXTRA_DIST augmentatio