On Sat, Dec 05, 2015 at 06:11:51PM +0100, Jonathan Matthew wrote:
> The main interesting bit here is the txeof and start loops, which previously
> operated based on the prod/cons indices and the contents of the tx queue,
> but now just uses the indices as that's the only way to get a consistent vie
On Fri, Dec 25, 2015 at 8:21 PM, Ricardo Mestre wrote:
> I made an inspection on userland tree and there quite a few applications still
> using strncpy(3) instead of strlcpy(3). Some of them may never need that
> safety
> since the boundaries are always fixed, nevertheless since strlcpy is a drop
Ricardo Mestre wrote:
> I made an inspection on userland tree and there quite a few
> applications still using strncpy(3) instead of strlcpy(3). Some of
> them may never need that safety since the boundaries are always fixed,
> nevertheless since strlcpy is a drop-in replacement it doesn't hurt to
Hello,
I made an inspection on userland tree and there quite a few applications still
using strncpy(3) instead of strlcpy(3). Some of them may never need that safety
since the boundaries are always fixed, nevertheless since strlcpy is a drop-in
replacement it doesn't hurt to use, plus it will alwa
Hi,
As X starts, it will attempt to detect features from the kbd(8)
setting--for example, us.dvorak will enable dvorak in X, and
fr.dvorak will enable French dvorak in X. However, it detects
these features with equality checks, which will fail if multiple
options are set, as in the case of us.dvor
On Fri, Dec 25, 2015 at 01:36:31PM -0500, Michael Reed wrote:
> It's had the ``Not implemented'' notice since ksh.1's initial import
> 19 years ago [1], so it's probably not going to be implemented.
>
> [1]:
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/ksh.1?rev=1.1&content-type=text/x-
On Fri, Dec 25, 2015 at 01:23:06PM -0500, Michael Reed wrote:
> Literal pipe characters are easier to read and there isn't any
> difference in the output for mandoc(1) -Thtml and -Tutf8.
>
> \*(Ba is still used elsewhere in ksh.1, although I didn't touch
> those as I'm unsure if this change is eve
It's had the ``Not implemented'' notice since ksh.1's initial import
19 years ago [1], so it's probably not going to be implemented.
[1]:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/ksh.1?rev=1.1&content-type=text/x-cvsweb-markup
Index: ksh.1
==
Literal pipe characters are easier to read and there isn't any
difference in the output for mandoc(1) -Thtml and -Tutf8.
\*(Ba is still used elsewhere in ksh.1, although I didn't touch
those as I'm unsure if this change is even wanted.
Index: ksh.1
===
Hi,
more is broken in printf(3).
Ingo Schwarze wrote on Fri, Dec 25, 2015 at 12:30:29AM +0100:
> Fourth file, fourth broken file.
> This is the worst bug found so far.
[...]
> When fprintf(fp, "...%ls...", ...) encounters an encoding error,
> it trashes fp BEYOND REPAIR, clearing all FILE flags,
Dear tech@ readers,
On Thu 24/12/2015 15:58, Alessandro DE LAURENZIS wrote:
[...]
> my second attempt... I understand that the previous patch was wrong.
>
> After digging into terminfo(5) man page, I think the problem could be
> related to the if...then...else structures (%?...%t...%e...%t...%;)
On Fri, Dec 25, 2015 at 02:34:12PM +0100, Mark Kettenis wrote:
> IMNSHO the code produced by OpenBSD's yacc should be portable;
> reallocarray isn't portable.
ok, thanks for clarifying
> Date: Fri, 25 Dec 2015 14:17:19 +0100
> From: Theo Buehler
>
> On Thu, Dec 24, 2015 at 12:41:28PM -0500, Michael McConville wrote:
> > 1. realloc acts like malloc when ptr == NULL
>
> Why not
>
> "#endif",
> - "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)",
> - "
On Thu, Dec 24, 2015 at 12:41:28PM -0500, Michael McConville wrote:
> 1. realloc acts like malloc when ptr == NULL
Why not
"#endif",
- "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)",
- "goto bail;",
- "newss = yyss ? (short *)realloc(yyss, newsiz
Hi Mark,
Mark Kettenis wrote on Fri, Dec 25, 2015 at 12:30:43PM +0100:
> frit...@alokat.org wrote:
>> it looks like there is a memory leak in libc. In file
>> "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called, but
>> never freed, when printf(3) is called.
> Not really a leak. That buf
Hi Fritjof,
frit...@alokat.org wrote on Fri, Dec 25, 2015 at 11:56:33AM +0100:
> it looks like there is a memory leak in libc.
> In file "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called,
> but never freed, when printf(3) is called.
I think that's a false positive. The pointer to the b
> Date: Fri, 25 Dec 2015 11:56:33 +0100
> From: frit...@alokat.org
>
> Hi tech@,
>
> it looks like there is a memory leak in libc. In file
> "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called, but
> never freed, when printf(3) is called.
Not really a leak. That buffer gets freed when f
Hi tech@,
it looks like there is a memory leak in libc.
In file "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called, but never
freed, when
printf(3) is called.
--F.
$ valgrind --leak-check=full --show-leak-kinds=all /usr/sbin/apm
==29572== Memcheck, a memory error detector
==29572== Copy
Go for it, IIRC there are a few new strcpy that will need care to change
to strlcpy but otherwise it should be easy enough.
On Thu, Dec 24, 2015 at 04:30:37PM -0500, Christian Heckendorf wrote:
> * Michael McConville [24.12.2015. @16:19:03 -0500]:
>
> > Christian Heckendorf wrote:
> > > A cou
19 matches
Mail list logo
