Hi,
Yarin wrote [2012-03-30 17:01+0200]:
> Hello,
>
> Is mbstowcs() suppose to null-terminate? I ask because, on OpenBSD 4.9
> (generic, no patches), it never null terminates.
> Even though the C90 draft seems to imply that it should when there's enough
> room.
>
> http://www.open-std.org/jtc1
Hi,
just want to post a corrected and better version which prints the
(correct) keycode on the left and the current assignments on the
right (if any).
The entire code is conditionalized on !SMALL.
Plain I/O tested a lot outside of wsconsctl(8).
wsconsctl(8) supports -f with default/-a, so i've al
Stuart Henderson wrote [2012-03-26 11:16+0200]:
> An addition to ignore .git files, some of us use git locally to track
> changes pre-commit and, just like the existing ignore entries for
> RCS/SCCS/CVS control files, there is no reason to import these to CVS
> without an explicit ignore.
Yeah!
Ad
Sorry folks for this shitty report, but i thought it's maybe
better to send it out than not to be able to sleep or so.
I guess it's somehow related to the rthread wait4() path, but of
course i dunno. Here's what's happened:
As "always" i did my weekly kernel+userland compilation this noon,
and i
Hi,
David Coppa wrote:
> still rocking hard
My old Athlon 1600+ blow dries something like
I'm gruvm up the country, where the memory tastes like wine.
Is this a regression, then??
--steffen
(peep)
Hello,
this patch adds the -not operator to find(1).
I personally always found -not easier to use due to shell
escaping, but today may laziness has bitten back.
And "it's just one more non-POSIX-compliant option".
--steffen
Index: usr.bin/find/find.1
=
(All compile-tested after applying the patches.)
--steffen
unifdef(1).
(Should complete bin and usr.bin.)
(Did i press 'g' all the time? Sorry if not!)
--steffen
Index: usr.bin/unifdef/unifdef.c
===
RCS file: /Users/steffen/arena/code.openbsd/src/usr.bin/unifdef/unifdef.c,v
retrieving revis
pax(1).
--steffen
Index: bin/pax/options.c
===
RCS file: /Users/steffen/arena/code.openbsd/src/bin/pax/options.c,v
retrieving revision 1.74
diff -a -p -u -r1.74 options.c
--- bin/pax/options.c 2 Dec 2010 04:08:27 - 1.74
diff3(1).
--steffen
Index: usr.bin/diff3/diff3prog.c
===
RCS file: /Users/steffen/arena/code.openbsd/src/usr.bin/diff3/diff3prog.c,v
retrieving revision 1.11
diff -a -p -u -r1.11 diff3prog.c
--- usr.bin/diff3/diff3prog.c 27 Oct 200
lpr(1).
--steffen
Index: usr.sbin/lpr/common_source/common.c
===
RCS file:
/Users/steffen/arena/code.openbsd/src/usr.sbin/lpr/common_source/common.c,v
retrieving revision 1.33
diff -a -p -u -r1.33 common.c
--- usr.sbin/lpr/common_so
uudecode(1).
--steffen
Index: usr.bin/uudecode/uudecode.c
===
RCS file: /Users/steffen/arena/code.openbsd/src/usr.bin/uudecode/uudecode.c,v
retrieving revision 1.17
diff -a -p -u -r1.17 uudecode.c
--- usr.bin/uudecode/uudecode.c 27 O
Wanted or not, here is the promised big diff which does the
following:
1. Encapsulate struct table iteration usage
(*All* direct accesses encapsulated with struct tstate.)
2. ktinit() shouldn't expect pow2 size requests..
(It's really better that way.)
3. Turn struct table over to node-based
And this smaller diff excludes the node-based table.
Since revision 1.8 (extra sanity checking for afree()) is the
youngest commit of alloc.c i guess that checking should not be
removed. But that unidirectional list walk is a real killer:
with the test from one of my former mails and 1 variab
Otto Moerbeek wrote [2012-02-19 08:49+0100]:
> while I did graduate on a theoretical computer science subject myself
I have no doubt about that. (?)
> I think this alternate hash table stuff is all overkill for ksh.
But a linear array based implementation with INT_MAX/2 is a heavy
thing. Did yo
Steffen Daode Nurpmeso wrote [2012-02-15 14:55+0100]:
> the patch below localizes access of struct table internals to
> table.c by using the ktwalk()/ktnext() interface from proto.h
> instead of doing handcrafted table iterations.
Yes it was wrong because it didn't take the flag
Hey all,
the patch below localizes access of struct table internals to
table.c by using the ktwalk()/ktnext() interface from proto.h
instead of doing handcrafted table iterations.
Surely a useful change regardless of possibly turning over to
a node-based hashmap approach.
--steffen
Index: bin/ks
It turns out that sys/hash.h also uses Chris Toreks hash algorithm
in the same 1:1 way that was present in Berkeley DB a decade ago.
So maybe "i prefer leaving optimization up to the compiler" should
be applied here, too. The patch does this.
And - you know, i never made it into that gcc(1) code
For one: Tobias Stoeckmann already stated more yesterday,
including that exit(3) in a signal handler is a bad thing.
(It surely should have been _exit(2).)
Version 3 (1) doesn't trash errno no more, (2) is hopefully less
messy and (3) does no longer introduce a new file, so also more
easyness for
==
RCS file: keycode.c
diff -N keycode.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ keycode.c 31 Jan 2012 13:46:22 -
@@ -0,0 +1,139 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2012 Steffen Daode Nurpmeso.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute thi
$OpenBSD$ */
+
+/*
+ * Copyright (c) 2012 Steffen Daode Nurpmeso.
+ * All rights reserved.
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission no
Index: sbin/wsconsctl/map_parse.y
===
RCS file: /Users/steffen/arena/code.openbsd/src/sbin/wsconsctl/map_parse.y,v
retrieving revision 1.4
diff -a -p -u -r1.4 map_parse.y
--- sbin/wsconsctl/map_parse.y 26 Jun 2008 05:42:06 -
Hey all interested,
while writing a small wscons(4) keycode utility i asked myself
why KS_GROUP_Ascii is named the way it is, since the (lower) byte
carries more information, at least eventually.
I looked around a bit, and found out that NetBSD did change the
name to KS_GROUP_Plain, which is in m
Ariane van der Steldt wrote [2012-01-14 08:42+0100]:
> As far as I'm concerned, this diff will be commited once we unlock after
> release (in a coordinated manner ofcourse, since this is uvm we're
> talking about).
> It's about time too, ofcourse: 64 revisions of the same diff is alot. :D
> --
> A
Ted Unangst wrote [2011-11-14 22:35+0100]:
> On Mon, Nov 14, 2011, Steffen Daode Nurpmeso wrote:
> > Is there a reason not to use CTASSERT (and some kind of
> > member_sizeof())? I couldn't find just any discussion on that in
> > marc and gmane.
>
> Seems lik
Hi,
my dhclient.c patch was very wrong.
And it (falsely) removed a runtime check of some struct member
size. But this very hunk (while wrong) led me to a question.
Since saving even some bytes in shell scripts counts so much,
i wonder why compile-time assertions are not used at all (AFAIK).
I.e.,
27 matches
Mail list logo