Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Adding new gcc warnings (Russ Allbery)
2. Re: Adding new gcc warnings (Julien ?LIE)
3. Re: Adding new gcc warnings (Russ Allbery)
4. Re: Buffindexed page size limited? (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Fri, 29 Dec 2017 10:47:04 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Adding new gcc warnings
Message-ID: <[email protected]>
Content-Type: text/plain
Russ Allbery <[email protected]> writes:
>> Couldn't -Wstack-protector along with -fstack-protector be useful?
> Added these to rra-c-util.
I take that back -- I apparently looked at this a while back and realized
it wouldn't be workable due to false positives with small buffers.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Fri, 29 Dec 2017 22:56:33 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Adding new gcc warnings
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Russ,
> More than four years later, I finally took a look at these changes to the
> INN warning flags. :) I think most of these changes were already made in
> INN, but I also updated rra-c-util in places.
Thanks!
>> -Wdeclaration-after-statement can sometimes be useful for clarity (for
>> instance declaring a variable only in the loop it is used). I do not
>> know whether this warning should really be enforced.
>
> Yeah, this has now been adopted as standard C. The risk is that INN would
> fail to compile on older C compilers that follow the previous standard
> (although I think GCC has always supported this). I still avoid this
> coding style myself, but I'm happy for INN to adopt declaration at use.
Now adopted for INN.
Only 3 changes needed, so that's pretty fine. The risk of a build failure
on older C compilers seems limited.
--- frontends/inews.c (r?vision 10206)
+++ frontends/inews.c (copie de travail)
@@ -448,6 +448,9 @@
char *buff;
char *out;
char *p;
+#ifdef DO_MUNGE_GECOS
+ int left = SMBUF - 1;
+#endif
#if !defined(DONT_MUNGE_GETENV)
memset(outbuff, 0, SMBUF);
@@ -464,7 +467,6 @@
* buffer. Remember that on some Unix systems, the content of the GECOS
* field is under (untrusted) user control and we could be setgid. */
p = pwp->pw_gecos;
- int left = SMBUF - 1;
if (*p == '*')
p++;
for (out = outbuff; *p && !GECOSTERM(*p) && left; p++) {
--- frontends/rnews.c (r?vision 10206)
+++ frontends/rnews.c (copie de travail)
@@ -491,6 +491,7 @@
#if defined(DO_RNEWSPROGS)
char path[(SMBUF * 2) + 1];
char *p;
+ int len;
#endif /* defined(DO_RNEWSPROGS) */
char buff[SMBUF];
const char *cargv[4];
@@ -580,8 +581,6 @@
}
#if defined(DO_RNEWSPROGS)
- int len;
-
cargv[0] = UNPACK;
cargv[1] = NULL;
/* Ignore any possible leading pathnames, to avoid trouble. */
--- nnrpd/nnrpd.c (r?vision 10206)
+++ nnrpd/nnrpd.c (copie de travail)
@@ -370,6 +370,10 @@
void
CMDcapabilities(int ac, char *av[])
{
+#ifdef HAVE_SASL
+ const char *mechlist = NULL;
+#endif
+
if (ac == 2 && !IsValidKeyword(av[1])) {
Reply("%d Syntax error in keyword\r\n", NNTP_ERR_SYNTAX);
return;
@@ -382,8 +386,6 @@
Printf("IMPLEMENTATION %s\r\n", INN_VERSION_STRING);
#ifdef HAVE_SASL
- const char *mechlist = NULL;
-
/* Check for available SASL mechanisms.
* Start the string with a space for the strstr() calls afterwards. */
sasl_listmech(sasl_conn, NULL, " ", " ", "", &mechlist, NULL, NULL);
> Note that -Wdeclaration-after-statement only applies at block scope, so a
> variable declared at the top of a loop should be fine, since that's the
> first statement inside a new block.
Ah, OK, I misunderstood it 4 years ago :)
>> -Wredundant-decls is not used in INN because of noise generated by system
>> headers.
>
> I've now fixed this. The noise from the system headers were really our
> fault due to some old legacy compatibility code that's fairly pointless
> now.
Building INN with Perl or Python support, I encounter warnings like:
In file included from perl.c:26:0:
/usr/lib/x86_64-linux-gnu/perl/5.20/CORE/perl.h:1296:8: error: d?claration
redondante de ??strerror?? [-Werror=redundant-decls]
char *strerror (int);
^~~~~~~~
In file included from ../include/clibrary.h:61:0,
from perl.c:19:
/usr/include/string.h:413:14: note: la d?claration pr?c?dente de ??strerror??
?tait ici
extern char *strerror (int __errnum) __THROW;
^~~~~~~~
/usr/lib/x86_64-linux-gnu/perl/5.20/CORE/perl.h:3862:8: error: d?claration
redondante de ??atof?? [-Werror=redundant-decls]
double atof (const char*);
^~~~
In file included from /usr/include/features.h:374:0,
from /usr/include/inttypes.h:25,
from ../include/clibrary.h:51,
from perl.c:19:
/usr/include/x86_64-linux-gnu/bits/stdlib-float.h:26:1: note: la d?finition
pr?c?dente de ??atof?? ?tait ici
__NTH (atof (const char *__nptr))
^
I've added a few pragmas like these ones, and it now builds fine:
+#pragma GCC diagnostic ignored "-Wredundant-decls"
#include <perl.h>
+#pragma GCC diagnostic warning "-Wredundant-decls"
+#pragma GCC diagnostic ignored "-Wredundant-decls"
#include "Python.h"
+#pragma GCC diagnostic warning "-Wredundant-decls"
> Added -Wmissing-declarations to rra-c-util. I haven't checked to see how
> many warnings would be generated in INN.
This warning flag is already enabled in INN.
> Added these to rra-c-util. -Wconversion -Wno-sign-conversion will
> probably require adding some cases; I had to make changes to both
> rra-c-util and C TAP Harness for those.
I'll see later for this one. I bet it will need some time to deal with.
--
Julien ?LIE
??Nam et ipsa scientia potestas est.?? (Francis Bacon)
------------------------------
Message: 3
Date: Fri, 29 Dec 2017 14:30:34 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Adding new gcc warnings
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Building INN with Perl or Python support, I encounter warnings like:
Oh, ack, thank you. I forgot to check that. Although I am a little
mystified by why you're getting warnings from paths that should be marked
as system headers....
Oh, hm, I bet the problem here is that the Perl and Python headers aren't
considered system headers because they're included with -I and not
-isystem and aren't in a system header path. I wonder if we could fix
that.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 4
Date: Fri, 29 Dec 2017 16:55:37 -0800
From: Russ Allbery <[email protected]>
To: Julien ?LIE <[email protected]>
Cc: "inn-workers\@lists.isc.org" <[email protected]>
Subject: Re: Buffindexed page size limited?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> On Fedora 18 ppc64, the overview/api.t test fails with:
> # buffindexed
> buffindexed: OV_HDR_PAGESIZE (16384) is not a multiple of pagesize (65536)
> Opening the overview database failed, cannot continue
> In storage/buffindexed/buffindexed.c:
> #define OV_HDR_PAGESIZE 16384
> if ((pagesize > OV_HDR_PAGESIZE) || (OV_HDR_PAGESIZE % pagesize)) {
> warn("buffindexed: OV_HDR_PAGESIZE (%d) is not a multiple of pagesize
> (%ld)", OV_HDR_PAGESIZE, pagesize);
> return false;
> }
> and config.h has:
> /* Define to 1 if you have the `getpagesize' function. */
> #define HAVE_GETPAGESIZE 1
> So I wonder whether there is a reason for having set OV_HDR_PAGESIZE
> to 16384 in the buffindexed source code.
> Couldn't we just set OV_HDR_PAGESIZE to pagesize if pagesize > 16384?
> This way, it would still work as it used to for existing working systems,
> and it would also work for systems having pagesize > 16384.
Very belatedly (more than four years later), I took a look at this and
concur with this evaluation. I moved the code around a bit to adapt the
page size to the the local system page size, hopefully in a way that works
properly.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 101, Issue 6
*******************************************
