Hi,
Starting to play with man.cgi (src/usr.bin/mandoc/cgi.c), it seems that
man.cgi will segfault if configuration file is absent or empty.
Here a patch that display error message and 505, like when MAN_DIR is
invalid.
Note: the segfault occurs in cgi.c:224 (http_parse), that assume
req->p is no
On Thu, Jul 17, 2014 at 8:05 PM, patrick keshishian wrote:
> Silly even though, the description of lsearch says it will modify
> ("it shall be added at the end of") the table, for which "base
> argument points to the first element"?
Ah, I didn't pay close attention to the definition and assumed i
On 7/17/14, Matthew Dempsky wrote:
> Hrm. It seems silly to me to change it to require a non-const pointer
> argument,
Silly even though, the description of lsearch says it will modify
("it shall be added at the end of") the table, for which "base
argument points to the first element"?
analogy:
Ran into this while running the regression suite for another patch.
The regression test for open_memstream causes a SIGBUS because it closes
the stream too early.
Replaced fclose with fflush since they both update pbuf and psize.
Added a similar check for fclose at the end.
Index: regress/lib/li
Hrm. It seems silly to me to change it to require a non-const pointer
argument, but POSIX, Linux, Solaris, FreeBSD, and NetBSD all use "void
*base" so it doesn't seem like we should have any ports tree issues
from changing it to be compatible either.
On Thu, Jul 17, 2014 at 6:04 PM, enh wrote:
>
Hm, is there a practical consequence of this? Seems like it would
only affect applications trying to store a reference to lsearch in a
function pointer of type "void (*)(const void *, void *, size_t *,
size_t, int (*)(const void *, const void *))"; do those exist?
On Thu, Jul 17, 2014 at 5:38 PM,
Since net.inet6.ip6.accept_rtadv is gone, the installer shouldn't
set it.
It is not obvious to me that enabling rediraccept is more important
for IPv6 than for IPv4, where we keep is disabled by default. Do
we want to kill that whole block?
Index: install.sh
=
2014-07-17 16:13 GMT+02:00 Stuart Henderson :
> On 2014/07/18 00:10, Jonathan Gray wrote:
>> sys.mk automatically gets included by make(1) and sets CXXFLAGS to
>> CFLAGS. If a Makefile defines additional CFLAGS they will then be
>> passed to the C++ compiler. Which creates problems with flags
>>
On Tue, Jul 15, 2014 at 12:13:58AM +0200, Maximilian Fillinger wrote:
> Something I forgot about during the discussion about the diff for dump:
> The manpage doesn't mention yet that we can specify the duid on the
> command line now.
>
fixed, thanks.
jmc
> --- sbin/dump/dump.8.orig Mon Jul
On Jul 17, 2014, at 1:39 PM, Jan Engelhardt wrote:
>
> On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>>
>> * The build system defaults --program-transform-name to the host triplet
>> when cross-compiling. It shouldn't do that as the library doesn't have
>> a target and is not a
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>
>* The build system defaults --program-transform-name to the host triplet
> when cross-compiling. It shouldn't do that as the library doesn't have
> a target and is not a cross-compiler (as far as I know). It certainly
> doesn't ma
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>
>* ioctl(FIONBIO) is used in a few files to make sockets non-blocking
> rather than using fcntl to set the the standard O_NONBLOCK bit. The
> files apps/s_client.c and apps/s_server.c should use BIO_socket_nbio()
> instead of direc
Thanks for the quick responses and convincing feedback. Mind my goal is
not to become a supported platform - at all - but rather to lower the
portability barrier where reasonable. I can easily patch around any
other concerns locally.
Brent: I'll email you the changes that there's agreement on so y
>On 17/07/14 04:26, Bob Beck wrote:
>> Steve, sorry, but GNU/kFreeBSD is not going to happen right now. We
>> are too busy with other things.
>
>I understand, actually I wasn't asking for that. I think having lots of
>platform-specific implementations would be unclean, I was only hoping
>the exist
Thanks for the feedback, Ingo! Sorry for the confusion. I'll spend some more
time with queue(3). :)
> On Jul 17, 2014, at 1:21, Ingo Schwarze wrote:
>
> Hi,
>
> Kent R. Spillner wrote on Wed, Jun 04, 2014 at 10:01:12AM -0500:
>
>> config(char *) contains a hand-rolled version of getlist(c
On 17/07/14 04:26, Bob Beck wrote:
> Steve, sorry, but GNU/kFreeBSD is not going to happen right now. We
> are too busy with other things.
I understand, actually I wasn't asking for that. I think having lots of
platform-specific implementations would be unclean, I was only hoping
the existing get
On 2014/07/18 00:10, Jonathan Gray wrote:
> sys.mk automatically gets included by make(1) and sets CXXFLAGS to
> CFLAGS. If a Makefile defines additional CFLAGS they will then be
> passed to the C++ compiler. Which creates problems with flags
> that should only be used by the C compiler in Makefi
sys.mk automatically gets included by make(1) and sets CXXFLAGS to
CFLAGS. If a Makefile defines additional CFLAGS they will then be
passed to the C++ compiler. Which creates problems with flags
that should only be used by the C compiler in Makefiles that
deal with both C and C++ (like Mesa).
Fi
18 matches
Mail list logo
