That's disgusting. If it's important to know where it failed, that's
why you call the regular funciton, check the error and say something
intelligent. Then it's easy to look at the code and know it's doing
the right thing, rather than having to wade through some macro and
gccisms. bleah.
I'd f
On Sun, Dec 16, 2012 at 01:01:49PM -0700, Theo de Raadt wrote:
> > know exactly where the memory allocation fails since the error messages
>
> I hate xstrdup() and xcalloc() for exactly that reason. You don't
> know why it failed.
Actually, you can make them macros using all that underscore gcc
On Sun, Dec 16, 2012 at 05:19:11PM -0500, Mike Erdely wrote:
> Since snmpd.conf stores passwords in plain text, should we prevent
> changes to its contents in security(8) output?
There are other files that do the same; e.g. ypldap.conf
I'm not saying your diff is wrong; just incomplete if you want
Since snmpd.conf stores passwords in plain text, should we prevent
changes to its contents in security(8) output?
-ME
Index: changelist
===
RCS file: /cvs/src/etc/changelist,v
retrieving revision 1.77
diff -u -p -r1.77 changelist
---
> I'm not opposed to introducing xstrdup() and xcalloc() to do the same
> thing, though I think one advantage of the current method is that we
> know exactly where the memory allocation fails since the error messages
> are very specific, e.g. "no memory for unpriv_ibuf" vs. "xcalloc: out of
> memor
On Thu, Dec 13, 2012 at 12:07:42PM +0100, Joerg Zinke wrote:
>
> Am 11.12.2012 um 04:12 schrieb Lawrence Teo :
>
> > There are a number of calloc() and strdup() calls in the
> > apply_defaults() and clone_lease() functions whose return values are not
> > checked. If they happen to return NULL, d
Hello,
playing with option-252 I found it already has a name. Found that as
well: http://marc.info/?l=openbsd-misc&m=126573542214773
Wrote a little script to find undocumented options, see end of message.
I moved some existing blocks when I found them to be in the wrong place.
Added a new sect
