Re: [hackers] Re: [PATCH] dd: Use sigaction(2) to obviate select(2)

2017-10-08 Thread Eric Pruitt 
On Sun, Oct 08, 2017 at 01:01:55PM -0700, Michael Forney wrote:
> I am curious why ubase dd is using splice instead of just read/write
> (as you noted most other implementations do). Unless there is a big
> performance win, I would think that simplicity and portability would
> be preferable.

I did some digging through the commit history when I created this patch
to find out why: the ubase dd(1) implementation is based on
https://github.com/stealth/odd.git which implements the techniques
described in http://stealth.openwall.net/papers/odd.pdf to improve the
performance of dd(1). That is not to say I agree the added complexity is
worth the performance improvement, but I at least understand the
motivation and think it's a reasonable goal.

Eric

Re: [hackers] Re: [PATCH] dd: Use sigaction(2) to obviate select(2)

2017-10-08 Thread Michael Forney 
On 2017-09-17, Eric Pruitt  wrote:
> On Sun, Sep 10, 2017 at 04:31:24AM -0700, Eric Pruitt wrote:
>> By setting the SIGINT handler with sigaction(2), automatic retries of
>> the splice(2) syscall can be disabled by not setting SA_RESTART. This
>> makes it possible to use Ctrl+C even if the "if" operand refers to the
>> controlling terminal. The SIGINT message has also been moved outside the
>> signal handler since fprintf(3) is not an async-signal-safe function.
>
> I'm wondering if the ubase maintainer(s) have looked at this patch and
> whether or not they think there are some problems with it.

I can reproduce the issue (select spinning) and I verified that the
patch does indeed fix the issue, so I think it should be applied.

I am curious why ubase dd is using splice instead of just read/write
(as you noted most other implementations do). Unless there is a big
performance win, I would think that simplicity and portability would
be preferable.

Re: [hackers] [dwm] fix keysyms processing by kfx_

2017-10-08 Thread Martin Kühne 
Aren't we depending on Xft already?

https://stackoverflow.com/questions/9838385/replace-of-xkeycodetokeysym#22418839

cheers!
mar77i

Re: [hackers] [dwm] fix keysyms processing by kfx_

2017-10-08 Thread Anselm Garbe 
Hi Hiltjo,

I don't really like this change, see below for the reasons.

On 30 September 2017 at 12:39, Hiltjo Posthuma  wrote:
> --- a/dwm.c
> +++ b/dwm.c
> @@ -988,16 +988,18 @@ void
>  keypress(XEvent *e)
>  {
> unsigned int i;
> -   KeySym keysym;
> +   KeySym *keysym;
> XKeyEvent *ev;
> +   int keysyms;
>
> ev = >xkey;
> -   keysym = XKeycodeToKeysym(dpy, (KeyCode)ev->keycode, 0);
> +   keysym = XGetKeyboardMapping(dpy, (KeyCode)ev->keycode, 1, );

if (keysym == NULL)
return;

> for (i = 0; i < LENGTH(keys); i++)
> -   if (keysym == keys[i].keysym
> +   if (keysym[0] == keys[i].keysym

Previously keysym was safe to be checked in this comparison. Now
keysym could point to NULL I presume and is never checked. Also I
dislike the array syntax here. KeySym is CARD32 afair. So this should
become

if (*keysym == keys[i].keysym

instead.

> +   XFree(keysym);

Now we start malloc/free'ing memory on every keypress? This sucks imho.

X has always been retarded.

Tbh I would stick to the deprecated function to avoid this retarded
malloc/free on every(!) keypress that was recognized. What moron came
up with such retarded API design?

BR,
Anselm