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.
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!
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
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
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
(All compile-tested after applying the patches.)
--steffen
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
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
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
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
---
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
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 you
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 flags into account
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:
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
--- /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 this software for any
+ * purpose
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 notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED
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
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
--
Ariane
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 like a good idea, but your patch is wrong.
Off
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).
25 matches
Mail list logo
