> On Tue, Feb 10, 2015 at 10:07:52PM +, Connor Lane Smith wrote:
>> int
>> utftorunestr(const char *s, Rune *p)
>> {
>> int i, n;
>>
>> for(i = 0; (n = chartorune(&p[i], s)), p[i] != 0; i++)
>> s += n;
>> return i;
>> }
>>
>> int
>> fgetrune(Rune *p, FILE *fp)
>> {
> > Yes, I speak about static linking, because It is what we have in
> > sbase, so dynamic linking is outside of this discussion (ant it is
> > not suckless :P). And maybe compilers are smarters, but the link
> > process is the same. Try it and you will see it. Even if you find
> > some too much sm
When started, slock doesn't blank the displays to colour 0 until a
slock to realise the input buffer is empty (i.e. backspace is hit). As
far as I can tell, this isn't the intended behaviour. This patch fixes
this problem such that as soon as slock is started, the display is
blanked to colour 0, ra
>From 3aeae0148a75a02e57c4d19b00b68dbb1773d848 Mon Sep 17 00:00:00 2001
From: Jakob Kramer
Date: Wed, 11 Feb 2015 01:59:04 +0100
Subject: [PATCH 2/3] add estrndup
---
libutil/ealloc.c | 17 +
util.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/libutil/eallo
>From e161205d2af1e163fb55f9e5683deaec76433a90 Mon Sep 17 00:00:00 2001
From: Jakob Kramer
Date: Wed, 11 Feb 2015 02:08:17 +0100
Subject: [PATCH 3/3] make use of en*alloc functions
---
expr.c | 8 ++--
grep.c | 16
sort.c | 9 ++---
3 files changed, 8 insertions(+), 2
>From 59ab03dc28a6d20283ac1cf47665b690deff3954 Mon Sep 17 00:00:00 2001
From: Jakob Kramer
Date: Wed, 11 Feb 2015 01:40:52 +0100
Subject: [PATCH 1/3] add en*alloc functions
---
libutil/ealloc.c | 38 +++---
util.h | 6 +-
2 files changed, 36 insert
On Tue, Feb 10, 2015 at 10:07:52PM +, Connor Lane Smith wrote:
> int
> utftorunestr(const char *s, Rune *p)
> {
> int i, n;
>
> for(i = 0; (n = chartorune(&p[i], s)), p[i] != 0; i++)
> s += n;
> return i;
> }
>
> int
> fgetrune(Rune *p, FILE *fp)
> {
> ch
On Tue, 10 Feb 2015 22:07:52 +
Connor Lane Smith wrote:
> It sounds like it might be a good idea to add these to the library.
> However, I have some simplification suggestions, especially to avoid
> memory allocation inside libutf. I've attached a file illustrating the
> functions as I think
This is a useful behavior if you want to reorder the lines,
because otherwise you might end up with originally two lines
on one, e.g.
$ echo -ne "foo\nbar" | sort
barfoo
>From 6a2b31c06be91a64fe6ea7acea65c00db3a336e0 Mon Sep 17 00:00:00 2001
From: Jakob Kramer
Date: Wed, 11 Feb 2
On Tue, 10 Feb 2015 21:45:29 +0100
k...@shike2.com wrote:
Hey k0ga,
> Yes, I speak about static linking, because It is what we have in
> sbase, so dynamic linking is outside of this discussion (ant it is
> not suckless :P). And maybe compilers are smarters, but the link
> process is the same. Try
Hi FRIGN,
It's been a while since I posted to this list. I do still maintain
libutf, though -- glad to hear it's still being of use.
It sounds like it might be a good idea to add these to the library.
However, I have some simplification suggestions, especially to avoid
memory allocation inside li
> When you write a library one of the objects is to minimize
> what code is included in the binary when the library is linked.
> When you link with a library you extract object files from the
> archive, so all the functions of the object file are included
> in the program, even if the program don't
> On Tue, 10 Feb 2015 21:21:56 +0100
> k...@shike2.com wrote:
>
> Hey k0ga,
>
>> When you write a library one of the objects is to minimize
>> what code is included in the binary when the library is linked.
>> When you link with a library you extract object files from the
>> archive, so all the f
On Tue, 10 Feb 2015 21:21:56 +0100
k...@shike2.com wrote:
Hey k0ga,
> When you write a library one of the objects is to minimize
> what code is included in the binary when the library is linked.
> When you link with a library you extract object files from the
> archive, so all the functions of th
On Tue, 10 Feb 2015 15:06:46 -0500
Greg Reagle wrote:
> Has anyone tried any software checkers on suckless programs? For
> example:
> - Electric Fence
> - DUMA
> - Memcheck of Valgrind
> - ProPolice
> - StackGuard
>
> Is there any interest in subjecting suckless software to such tests? I
> ha
Good evening,
>
> What is left to discuss is where to put these functions. I would propose
> to place chartorunearr into rune.c, where already chartorune() and
> others reside.
> I would place readrune() and writerune() into a new file called
> runeio.c.
> The name doesn't really matter, becaus
Greetings. I am excited to see all the recent progress on sbase.
Has anyone tried any software checkers on suckless programs? For
example:
- Electric Fence
- DUMA
- Memcheck of Valgrind
- ProPolice
- StackGuard
Is there any interest in subjecting suckless software to such tests? I
have not u
On 10 February 2015 at 19:23, Ralph Eastwood wrote:
> Hi,
>
> Attached patch gives support for uuencode -m, base64 encoding and decoding
> in uudecode.
> Flag, -o, added so that uudecode can output to stdout to override the
> output in encoded files.
>
> uudecode -m is accepted but ignored - the
Hi,
Attached patch gives support for uuencode -m, base64 encoding and decoding
in uudecode.
Flag, -o, added so that uudecode can output to stdout to override the
output in encoded files.
uudecode -m is accepted but ignored - the patch has an autodetection of the
file (begin-base64) in the header.
Good evening fellow hackers,
working with sbase, we've decided a while ago to include libutf in the
repo and base all tools' UTF-8-support on it instead of the insane
wchar.h-interface.
Now that almost all tools have UTF-8-support, we, along the way,
implemented a number of utility functions which
Greetings.
On Tue, 10 Feb 2015 19:07:34 +0100 Markus Teich
wrote:
> Heyho,
>
> here is my atempt to Christophs proposal. There are a few rough edges though:
>
> * On my mouse buttons 8 and 9 are used for the prev/next navigation. I
> thought 4
> and 5 would be standard, but could not test w
On Tue, Feb 03, 2015 at 03:18:59PM -0800, Evan Gates wrote:
> Hello,
>
> I finally have a new sed implementation. It's littered with FIXMEs and
> there are some points that need to be discussed, but for the most part
> it works like it should. It definitely has some work until it sucks
> less.
I'
22 matches
Mail list logo
