> It's in man signal.
>
> The only thing you can't use is floating point, because dtoa is crazy,
The *5 table, yes.
I tried to improve the situation there. I nearly lost my mind.
On Thu, May 23, 2013 at 21:38, Theo de Raadt wrote:
>> In glibc snprintf has a memory allocation failure mode.
>> I'm curious: is
>> OpenBSD committed to avoiding extensions (locale features, etc) which might
>> trigger allocation failure?
Yes. I mean, what in the world is snprintf doing allocati
> On Thu, May 23, 2013 at 05:05:45PM -0400, Ted Unangst wrote:
> > I was looking at mandoc and noticed it has too many strlcats (a common
> > affliction affecting quite a few programs.) It's faster and simpler to
> > use snprintf.
>
> In glibc snprintf has a memory allocation failure mode.
In Ope
On Thu, May 23, 2013 at 05:05:45PM -0400, Ted Unangst wrote:
> I was looking at mandoc and noticed it has too many strlcats (a common
> affliction affecting quite a few programs.) It's faster and simpler to
> use snprintf.
In glibc snprintf has a memory allocation failure mode. I'm curious: is
Ope
just pfctl_osfp.c. harder to replace strlcat when it's in a loop, but
some of the straight line calls can be done as snprintf followed by
one strlcat. worth it?
Index: pfctl_osfp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/pfctl_osfp.c,
I was looking at mandoc and noticed it has too many strlcats (a common
affliction affecting quite a few programs.) It's faster and simpler to
use snprintf.
The code in roff.c was doing something twisty with the length argument
to strlcpy. Doing fancy length tricks kind of defeats the purpose of
ha
On Thu, May 23, 2013 at 19:55, Gregory Edigarov wrote:
>> That's just a string compare. The remote host can send any string it
>> wants.
>>
> yes, it doesn't do any host resolution itself and there is no need in this,
> because syslogd already does this. (the resolution happens in main cycle,
> na
On 05/23/2013 07:20 PM, Ted Unangst wrote:
On Thu, May 23, 2013 at 12:57, Gregory Edigarov wrote:
On 05/22/2013 06:39 PM, Ted Unangst wrote:
On Wed, May 22, 2013 at 12:06, Gregory Edigarov wrote:
works for me, with only one limitation: now only for resolvable hosts, i.e
one cannot have
+192.1
On Thu, May 23, 2013 at 12:57, Gregory Edigarov wrote:
> On 05/22/2013 06:39 PM, Ted Unangst wrote:
>> On Wed, May 22, 2013 at 12:06, Gregory Edigarov wrote:
>>>
>>> works for me, with only one limitation: now only for resolvable hosts, i.e
>>> one cannot have
>>> +192.168.2.1
>>> * /some
On 2013/05/23 15:03, Sebastian Benoit wrote:
> Stuart Henderson(st...@openbsd.org) on 2013.05.22 21:18:05 +0100:
> > On 2013/05/22 20:47, Stuart Henderson wrote:
> > > does anyone see a downside to this?
>
> i see none other than making the maze of options of route(8) a bit more
> bizarre.
>
> >
Stuart Henderson(st...@openbsd.org) on 2013.05.22 21:18:05 +0100:
> On 2013/05/22 20:47, Stuart Henderson wrote:
> > does anyone see a downside to this?
i see none other than making the maze of options of route(8) a bit more
bizarre.
> > if the address family is not
> > explicitly specified, ass
> no, it is really a resolvable hosts.
It is unsafe.
On 05/22/2013 06:39 PM, Ted Unangst wrote:
On Wed, May 22, 2013 at 12:06, Gregory Edigarov wrote:
works for me, with only one limitation: now only for resolvable hosts, i.e
one cannot have
+192.168.2.1
* /some/file
Looking at the diff, I think it's not resolvable hosts, but what
The TOS class isn't (and can't be) used to match packets to the state. Once you
have created state from a packet with one TOS class, other packets with the
same src/dest ip/port match this state even if the class is different. (It has
to be this way - say you are natting - you wouldn't want a di
14 matches
Mail list logo
