> There is a compile time boundary
> check on the number of tags in dwm.
> Still, considering sl software is targeted at elite users
> it's not necessary IMO.
>
Ok, after reading the opinion of other developers I think we should
avoid the comparision. And I don't agree it is difficult catch this
On Thu, 10 Oct 2013 21:06:33 +0200
Christoph Lohmann <2...@r-36.net> wrote:
> There are no users in suckless. There are only developers. Users have to
> use gnome. So knowing array boundaries and pointers is a must. If you
> would design config.h for end users, well you are already lost with t
Hi.
There is a compile time boundary
check on the number of tags in dwm.
Still, considering sl software is targeted at elite users
it's not necessary IMO.
~k
Christoph Lohmann <2...@r-36.net> wrote:
>Greetings.
>
>On Thu, 10 Oct 2013 21:06:33 +0200 sin wrote:
>> On Thu, Oct 10, 2013 at 08:56:0
Greetings.
On Thu, 10 Oct 2013 21:06:33 +0200 sin wrote:
> On Thu, Oct 10, 2013 at 08:56:05PM +0200, Roberto E. Vargas Caballero wrote:
> > > It's runtime segfault (that may be rare and hard to catch) that is
> > > worth exactly one additional check.
> >
> > Ok, we don't agree about this topic,
On Thu, Oct 10, 2013 at 08:56:05PM +0200, Roberto E. Vargas Caballero wrote:
> > It's runtime segfault (that may be rare and hard to catch) that is
> > worth exactly one additional check.
>
> Ok, we don't agree about this topic, so I would like listen the opinion
> of other suckless developers in
> It's runtime segfault (that may be rare and hard to catch) that is
> worth exactly one additional check.
Ok, we don't agree about this topic, so I would like listen the opinion
of other suckless developers in order to take a decision.
--
Roberto E. Vargas Caballero
___
2013/10/9 Roberto E. Vargas Caballero :
> I think we shouldn't check this kind of things, because otherwise
> we must check all the parameters from config.h, and it is not done now.
> I usually check all the parameters which come from the user, and trust
> parameters from the own code, because they
> The other way it is NULL is if the user leaves the string out
> completely, in which case it will default-initialize to NULL. Maybe
It is true, it is other way of getting it, but it is also other error
of the user
>
> But thinking a bit more, if the button and mask match, then st should
> at
On Mon, Oct 7, 2013 at 9:17 PM, Roberto E. Vargas Caballero
wrote:
> mk->s is a string that are assigned in config.h, so I don't think we
> should check aginst NULL, because the only way it becomes NULL is
> a stupid user who put a NULL in it, and this case let to the luser
> get a good BOM!
for(mk = mshortcuts; mk < mshortcuts + LEN(mshortcuts); mk++) {
if(e->xbutton.button == mk->b
- && match(mk->mask, e->xbutton.state)) {
+ && match(mk->mask, e->xbutton.state)
+ && mk->s
> Oops, I realized after a pull that I tried to break style (by
> declaring a local not at the top of a function). I've corrected that
> and also rebased these three on the current head.
>
Ok, I will push these changes in the end of this week.
Best regards,
--
Roberto E. Vargas Caballero
On Sun, Oct 6, 2013 at 12:24 PM, Mark Edgar wrote:
> Oh, and let's do the same for Mousekey while we're at it.
Here's a patch file for that. This one has correct behavior in case
the user neglects to initialize .s in a Mousekey entry.
-Mark
0004-Avoid-buffer-overrun-in-bpress.patch
Descri
Oh, and let's do the same for Mousekey while we're at it.
-Mark
Avoid buffer overrun in bpress().
Use correct type for Mousekey.b (XButtonEvent.button).
--- a/st.c
+++ b/st.c
@@ -256,9 +256,9 @@ typedef struct {
} XWindow;
typedef struct {
- int b;
+ uint b;
uint mask;
- char s[ESC_BU
Oops, I realized after a pull that I tried to break style (by
declaring a local not at the top of a function). I've corrected that
and also rebased these three on the current head.
-Mark
0001-Simplify-Mod1-logic-in-kpress-eliminating-locals-and.patch
Description: Binary data
0003-New-ttys
OK, I've split this change into three patches. The cumulative affect
of these is:
kpress() is now much more straightforward and has no memcpy() calls.
selnotify() now supports MODE_ECHO. I couldn't remove the cast there however.
A new ttysend() function replaces all ttywrite();techo() sequences.
> Maybe I talked too much fast, and maybe we don't have to echo all the things
> we write to the tty with ttywrite. Let's me test it with some emulators and
> with my real terminal. I will send the results.
>
865:ttywrite(buf, len);
3459: ttywrite("\033[I", 3);
3464:
> > I think it might be a good idea to move
> > ttywrite();if(MODE_ECHO)techo() into its own function. It also appears
> > in bpress().
> >
>
> I agree, because always we call to ttywrite we should check the echo flag,
> and there are some places where it is not true (for example in mousereport).
On Wed, Oct 02, 2013 at 09:36:27AM +0200, Mark Edgar wrote:
> On Tue, 1 Oct 2013 23:04:16 +0200, Roberto E. Vargas Caballero wrote:
> > I agree here, good catch and good implementation. Could you send
> > a mail with the patch and a proper commit message?
>
> No problem!
I think we could avoid so
On Tue, 1 Oct 2013 23:04:16 +0200, Roberto E. Vargas Caballero wrote:
> I agree here, good catch and good implementation. Could you send
> a mail with the patch and a proper commit message?
No problem!
I think it might be a good idea to move
ttywrite();if(MODE_ECHO)techo() into its own function.
> >> > +#define STRNLEN(s) ((s)[LEN((s)) - 1] == '\0' ? strlen((s)) : LEN((s)))
> >> This trick is only useful when you usually have strings with a size of
> >> LEN(s)-1, but in our case we will usually have string with a small size,
> >> so it means we always will add a new test before of calling
2013/10/2 Mark Edgar :
> On Mon, 23 Sep 2013 10:06:13 +0200, Roberto E. Vargas Caballero wrote:
>> On Sat, Sep 21, 2013 at 03:41:01PM +0200, Mark Edgar wrote:
>> I don't agree here, because if you insert a escape sequence is not dificult
>> get more of 16 characters (for example a key combination w
On Mon, 23 Sep 2013 10:06:13 +0200, Roberto E. Vargas Caballero wrote:
> On Sat, Sep 21, 2013 at 03:41:01PM +0200, Mark Edgar wrote:
> I don't agree here, because if you insert a escape sequence is not dificult
> get more of 16 characters (for example a key combination which updates the
> bar title
22 matches
Mail list logo