Re: [hackers] [sbase][patches] sort makefile and add getconf guard file

2016-10-03 Thread FRIGN
ainline soon. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [sbase][patch]find: copy path before using basename

2016-10-03 Thread FRIGN
fnmatch((char *)arg->extra.p, path, 0); Please don't use VLA's. Use estrdup() in this case. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [sbase][patches] sort makefile and add getconf guard file

2016-10-03 Thread FRIGN
getconf.sh doesn't get run multiple times in parallel. This could be solved a bit more elegantly. You can see that getconf.sh generates the files confstr_l.h, limits_l.h, sysconf_l.h and pathconf_l.h. Maybe you can work something out. :) Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [PATCH] [slock] Remove faulty example and add a section on security considerations

2016-09-28 Thread FRIGN
th Xkb sadly. > Fair point, I shall fix this. You cannot fix this at this level. As Markus already pointed out, you have to carefully handle the options not to "destroy" the layout at the end. Also, what if some automated script changes the options regularly? You cannot cache the options

Re: [hackers] [PATCH] [slock] Remove faulty example and add a section on security considerations

2016-09-28 Thread FRIGN
t; while this should obviously be forbidden on a locked screen. What you do is call system("doas setxkbmap -option &"); which disables Ctrl+Alt+Backspace for the entire session. So you can only kill your X server until you have locked your screen once. It won't work afterwards, whic

Re: [hackers] [PATCH] [slock] Remove faulty example and add a section on security considerations

2016-09-28 Thread FRIGN
n string. If for any reason it is changed while slock is running (automation, whatever), and we uncache it, this can lead to strange behaviour. Cheers FRIGN -- FRIGN <d...@frign.de>

[hackers] [PATCH] [slock] Remove faulty example and add a section on security considerations

2016-09-28 Thread FRIGN
structions. Cheers FRIGN -- FRIGN <d...@frign.de> >From 2e363c4dfc98153f8067df27673dda9047ab9227 Mon Sep 17 00:00:00 2001 From: FRIGN <d...@frign.de> Date: Wed, 28 Sep 2016 20:20:51 +0200 Subject: [PATCH] Remove faulty example and add a section on security considerations The gi

[hackers] [sinit] [PATCH] Use switch for fork()

2016-09-23 Thread FRIGN
. ;) With best regards FRIGN -- FRIGN <d...@frign.de> >From 6365fab78c11e8269447cf0cfcbb1aeac618488b Mon Sep 17 00:00:00 2001 From: FRIGN <d...@frign.de> Date: Fri, 23 Sep 2016 09:37:59 +0200 Subject: [PATCH] Use switch for fork() This saves us one local variable and 2 lines of code,

Re: [hackers] [slock] [PATCHSET] Some improvements and more security

2016-09-12 Thread FRIGN
stems (in some cases it is sensitive to $USER, in others it is not). > Get rid of it. I'll send in a small patch when I have the time. Cheers FRIGN [0]:http://git.suckless.org/slock/commit/slock.c?id=0f1157d7e6cabe0394ffc35a0a58a30507af8ebd -- FRIGN <d...@frign.de>

Re: [hackers] [slock] [PATCHSET] Some improvements and more security

2016-09-12 Thread FRIGN
bly unleashing it to the public (IRC chat, whatever). But this is a minor thing imho. DPMS stays out and there's no need imho for such a long comment to reflect that. > Anyway, thanks for the work! I was happy to do it! :) Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] [PATCHSET] Some improvements and more security

2016-09-11 Thread FRIGN
On Sun, 11 Sep 2016 23:24:20 +0200 FRIGN <d...@frign.de> wrote: > See attached. Most important is the patch which removes the > abomination of user $USER which actually poses quite a risk and only > is done on part of the systems. So you can test this, do the following

[hackers] [slock] [PATCHSET] Some improvements and more security

2016-09-11 Thread FRIGN
. The largest one is the one removing global state of the program to make code audits simpler. Cheers FRIGN -- FRIGN <d...@frign.de> >From 86c4a4edc72958461c9142d218ac0a285751e708 Mon Sep 17 00:00:00 2001 From: FRIGN <d...@frign.de> Date: Sun, 11 Sep 2016 23:08:19 +0200 Subj

Re: [hackers] [slock] [PATCH] Properly drop privileges

2016-09-09 Thread FRIGN
cases. The midway cannot be solved by us, but we need to put trust into the facilities provided by the system and allow the users to be flexible (for instance, one could also create a slock user, so it would be bad to implicitly set the groups from the user and vice versa). > Thanks for the contribution, FRIGN. I was happy to do it! Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] [PATCH] Properly drop privileges

2016-09-07 Thread FRIGN
nogroup. It's also been the standard value for quark since forever. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] [PATCH] Properly drop privileges

2016-09-07 Thread FRIGN
On Wed, 7 Sep 2016 15:25:56 +0200 FRIGN <d...@frign.de> wrote: > Quentin found a problem on OpenBSD which was due to the negligient use of the passwd struct pointer. Given it points to static memory, we ended up with a "different" struct when we went to se the privilege dr

Re: [hackers] [slock] [PATCH] Properly drop privileges

2016-09-07 Thread FRIGN
On Wed, 7 Sep 2016 15:17:11 +0200 FRIGN <d...@frign.de> wrote: > Okay, this is hopefully the last iteration. -- FRIGN <d...@frign.de> >From e308e34f49c89612ecdd17e989483c211453b6cb Mon Sep 17 00:00:00 2001 From: FRIGN <d...@frign.de> Date: Wed, 7 Sep 2016 13:32:29 +0200

Re: [hackers] [slock] [PATCH] Properly drop privileges

2016-09-07 Thread FRIGN
On Wed, 7 Sep 2016 15:15:03 +0200 FRIGN <d...@frign.de> wrote: > Forget this patch, I forgot to remove my 1337 debugging line system("id"); return 0; from it. See attached for the fixed version. Sorry for the noise. Cheers FRIGN -- FRIGN &l

[hackers] [slock] [PATCH] Properly drop privileges

2016-09-07 Thread FRIGN
the supplementary groups. There really should not be any security compromises with a setuid application like slock. Cheers FRIGN -- FRIGN <d...@frign.de> >From dbb170d18380a4c20c5a074e68a4f481f17d3d5e Mon Sep 17 00:00:00 2001 From: FRIGN <d...@frign.de> Date: Wed, 7 Sep 2016 13:32:29 +0200

Re: [hackers] [slock] Unify how we check passwords between different OSes

2016-09-06 Thread FRIGN
es, which is not a very sane thing to do. If this patch is applied, I'll send my patch for slock as well to do the privilege drop properly. Currently, the privilege drop on Linux does not reset supplementary groups; this is adressed in the upcoming patch as well. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

2016-09-05 Thread FRIGN
On Mon, 5 Sep 2016 10:05:16 +0200 FRIGN <d...@frign.de> wrote: > [...], but I respect the per-process style. Of course I meant "per-project style". -- FRIGN <d...@frign.de>

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

2016-09-05 Thread FRIGN
r structs. I don't see a good reason to use typedefs in dwm/dmenu in the first place, but I respect the per-process style. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

2016-09-05 Thread FRIGN
action" just like using if () { } else if () { if () { } else { } } trees just not to have gotos in the code. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

2016-09-05 Thread FRIGN
t least make it visually half-appealing by "shortening" their code with struct typedefs. If your code has become so complex and overwhelming that plain "struct structname" constructs can't be fitted in there any more you should fix it. That's my opinion. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

2016-09-05 Thread FRIGN
r, if you cannot discern a type name from a variable name it's your problem and should not be "fixed" by having a strange use of sizeof which is error-prone, as Ali has well shown. This obviously goes the other way around too. One should not use variable names that can be misinterpreted as

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

2016-09-05 Thread FRIGN
sizeof(struct hw) shows clearly it's a type, whereas sizeof(homework) is not clear. But this is more a criticism of extreme typedeffing. Stop using typedefs for structs and you won't have this problem any more. If you can't discern type names from variable names, this is your pr

Re: [hackers] [quark] Use sizeof() instead of magic constants || FRIGN

2016-09-05 Thread FRIGN
not "necessary" to have parentheses for variable sizeof's. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [quark] missing newline

2016-09-04 Thread FRIGN
On Fri, 02 Sep 2016 17:26:12 +0300 "Ali H. Fardan" <r...@firemail.cc> wrote: > sorry, wrong patch Thanks! :) http://git.suckless.org/quark/commit/?id=12ebbc5dedfb212af3b93bb1762aec31bb59562f -- FRIGN <d...@frign.de>

Re: [hackers] [sbase] a question regarding date(1)

2016-09-01 Thread FRIGN
$ tool -f farg arg when the flag f takes a mandatory argument farg the resulting argc for instance is 1 (and *argv points at "arg"). I hope that explains things. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] Fix my previous commit and some light refactoring

2016-09-01 Thread FRIGN
to wait indefinitely after forcefully ungrabbing input; so we just wait for the user to release his keys (if it takes 2 seconds or whatever, say Mr. Plinkett uses his Linux box :P). Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] Fix my previous commit and some light refactoring

2016-09-01 Thread FRIGN
d of the four next commits fixes that. > The other three try to move duplicated behaviour inside unique > functions and move global variables inside functions which > exclusively need them. Patches following. the patches look good to me and I would favor them to be merged. Thanks for your wo

Re: [hackers] [slock] [PATCH] simplify fix for CVE-2016-6866

2016-08-31 Thread FRIGN
with a bogus "x" as password just > to see if the pws value is correct and other system requirements are > met to call crypt later on after the password has been entered. > > I will apply it tomorrow if there are no objections. are you sure we are not hitting any TOCTTOU proble

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread FRIGN
lock: unable to grab mouse pointer for > screen %s\n", > + screen); > … > + fprintf(stderr, > + "slock: unable to grab keyboard for screen > %s\n", > + screen); this looks like a good compromise. :) Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] Exit as soon as possible on input grabbing error

2016-08-30 Thread FRIGN
h. We intensely discussed this on IRC and it is the only sane way to make sure the behaviour is proper. Timing heuristics are never good. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] [PATCH] Refactor main()

2016-08-22 Thread FRIGN
us, same with file descriptors. The cleanup is done at the end anyway, so I thought I add it in places where we also return prematurely to make it possible in the future to spot the places where we might have to release locks manually. The X-Server is pretty strange in many aspects and the entire

Re: [hackers] [slock] [PATCH] Refactor main()

2016-08-22 Thread FRIGN
iew, and I'm confident that this is given here on our mailing list (as we can also observe with my patch). :) I corrected it accordingly, as you probably have already seen. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] [PATCH] Refactor main()

2016-08-22 Thread FRIGN
Oh yeah, good catch! > > diff --git a/util.h b/util.h > > index 6f748b8..4f170a2 100644 > > --- a/util.h > > +++ b/util.h > > @@ -1,2 +1,6 @@ > > +#include "arg.h" > > + > > +extern char *argv0; > > + > > #undef explicit_bzero &g

Re: [hackers] [slock] [PATCH] Refactor main()

2016-08-22 Thread FRIGN
On Mon, 22 Aug 2016 10:59:16 +0200 Anselm R Garbe <garb...@gmail.com> wrote: > I prefer it this way. So is it good to merge? Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] [PATCH] Refactor main()

2016-08-22 Thread FRIGN
y a bit. But again, if it is your explicit desire, I can create a version of the patch with the brackets removed. Cheers FRIGN -- FRIGN <d...@frign.de>

[hackers] [slock] [PATCH] Refactor main()

2016-08-22 Thread FRIGN
and makes the code more readable by pulling in arg.h, which has proven to be very useful in the last few years. Please provide feedback on this patch and test it. Cheers FRIGN -- FRIGN <d...@frign.de> >From 3c8552d65a0cd999e0f485669e5c99ea7c3399a4 Mon Sep 17 00:00:00 2001 From:

Re: [hackers] [sent] Fix error-messages || FRIGN

2016-08-12 Thread FRIGN
e \n and it's easy to miss given some errors rarely happen. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [sxiv] Discussion

2016-08-09 Thread FRIGN
On Sun, 7 Aug 2016 23:33:58 +0100 Dimitris Papastamos <s...@2f30.org> wrote: > hackers@ is not the right place for this kind of discussion. My bad, I'll repost this on dev@. -- FRIGN <d...@frign.de>

Re: [hackers] Re: [slock][patch] clear passwords with explicit_bzero

2016-08-07 Thread FRIGN
On Sun, 7 Aug 2016 13:03:48 +0200 Hiltjo Posthuma <hil...@codemadness.org> wrote: > Can someone apply this patch or give a reason why it sucks? :) I second this patch. -- FRIGN <d...@frign.de>

[hackers] [sxiv] Discussion

2016-08-07 Thread FRIGN
implied beauty[1]. Do I really need to dig around github now to see what the commit fixed? What do you think? Cheers FRIGN [0]:http://git.suckless.org/sxiv/tree/ [1]:http://git.suckless.org/sxiv/commit/?id=53a72c7b657d9dc3347d9d68e0b9a00773efe732 -- FRIGN <d...@frign.de>

Re: [hackers] [dmenu] Print highlighted input text only on single match || Quentin Rameau

2016-07-26 Thread FRIGN
On Tue, 26 Jul 2016 22:52:16 +0200 (CEST) g...@suckless.org wrote: > Print highlighted input text only on single match You probably merged the wrong branch here mate. -- FRIGN <d...@frign.de>

[hackers] [sent] add ff and ff.bz2 support in config.def.h

2016-07-14 Thread FRIGN
Hello everybody, I wrote a patch as an addition to config.def.h to support ff and ff.bz2 images. Let me know what you think. Cheers FRIGN -- FRIGN <d...@frign.de> >From c8504ac1a1f1f508fc0989bdc8d0a59c8efd2d98 Mon Sep 17 00:00:00 2001 From: FRIGN <d...@frign.de> Date: Thu, 14

Re: [hackers] [farbfeld] Add support for .bz2 to 2ff

2016-07-14 Thread FRIGN
On Thu, 14 Jul 2016 10:38:05 +0200 FRIGN <d...@frign.de> wrote: > { "\\.ff.bz2$", "bunzip | 2ff" }, my bad, it has to be { "\\.ff.bz2$", "bunzip" }, -- FRIGN <d...@frign.de>

Re: [hackers] [farbfeld] Add support for .bz2 to 2ff

2016-07-14 Thread FRIGN
}; with the same effect. Can you give me a good reason or context example where adding the compression support to 2ff proves to be useful? Cheers FRIGN [0]: http://git.suckless.org/sent -- FRIGN <d...@frign.de>

Re: [hackers] [dwm][PATCH] gaps

2016-07-11 Thread FRIGN
you bloody serious? -- FRIGN <d...@frign.de>

Re: [hackers] [sbase][PATCH] printf: support escaping '%' with '%%'. See printf(1p) EXAMPLES section.

2016-06-26 Thread FRIGN
On Sat, 25 Jun 2016 19:11:09 +0200 pranomostro <pranomes...@gmail.com> wrote: Hey Pranomostro, nice catch! Care to send it as a git-patch? Cheers FRIGN > --- > printf.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/printf.c b/printf.c >

Re: [hackers] [swerc] local suckless.org copyright notice || Anselm R Garbe

2016-06-13 Thread FRIGN
On Mon, 13 Jun 2016 14:17:01 +0200 (CEST) g...@suckless.org wrote: > - 2006-2013 suckless.org community | href="http://garbe.us/Contact;>Impressum > + 2006-2015 suckless.org community | href="http://garbe.us/Contact;>Impressum Isn't it 2016? -- FRIGN <d...@frign.de>

Re: [hackers] [scc] Revert "[driver] use pointers in tools lookup table" || Quentin Rameau

2016-06-07 Thread FRIGN
l. The idiom of making a pointer struct-array was circumvented to avoid doing that. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [scc] Revert "[driver] use pointers in tools lookup table" || Quentin Rameau

2016-06-07 Thread FRIGN
ot to drop before pushing. > Sorry for the noise. I was already wondering. If you had applied that change, you would've also had to make the changes in the arch-code-lookup-tables. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy

2016-06-06 Thread FRIGN
rbage. However, at least this garbage won't blow up in your face. > PD: I don't want to begin a flame war, but please, stop > of being a fan boy and think for yourself, try to find > the strong points and what is propaganda. Maybe you should evaluate your position a bit better before going all grandpa here on this ml. Your first code example is embarassing and shows that despite your high skill in C you seem to be fighting the wrong war here. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy

2016-06-05 Thread FRIGN
shit, thanks. there is also another point here: strlcpy is safer than strcpy and strncpy because _if_ there is an overflow the string will be 0-terminated. I'm not sure if there even should be an error-out in case for instance we overflow writing the "broken"-state-string to a client-name. Cheer

Re: [hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy

2016-06-05 Thread FRIGN
I just saw that I forgot to amend this part of the patch to this one here. Will push it later, like the following: if (strlcpy(..., size) >= size) ... The only reason why strlcpy is "non-portable" is because the Posix-committee has sticks up their asses (same with the gl

Re: [hackers] [libzahl] Switch to ISC license. || Mattias Andrée

2016-06-02 Thread FRIGN
on here about this. I don't care abour your opinion that much anyway. Cheers FRIGN -- FRIGN <d...@frign.de>

[hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy

2016-06-02 Thread FRIGN
Hello fellow hackers, I'll drop this little patch here so we finally make the switch to the safe OpenBSD-functions for string copying. Read the patch description for more info. Cheers FRIGN -- FRIGN <d...@frign.de> >From 849a7cbee0310beb7ea51986bf98aff8d3b7ff26 Mon Sep 17 00:00:00

Re: [hackers] [libzahl] Switch to ISC license. || Mattias Andrée

2016-06-02 Thread FRIGN
eeded, afaik there is none. Commercial law is pretty clear in this case. If something blows your computer up, you could theoretically sue. So yeah, let's keep it. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers][ubase][tput] tput(1)

2016-05-22 Thread FRIGN
t): ansic:18805 (97.57%) awk:255 (1.32%) sh: 213 (1.11%) do you really think it's a good idea to increase its size by roughly 10% to accomodate one single command? Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [farbfeld] [PATCH] Improve fread error handling in ff2*

2016-05-19 Thread FRIGN
d in fread(3). thank you very much for this patch! I've applied it. Very good work! Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [dwm][PATCH] Corrected typo.

2016-04-24 Thread FRIGN
ou are right. It's general convention that we don't use capital letters here. That's why this patch is wrong. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [farbfeld] Remove dimension checks || FRIGN

2016-04-11 Thread FRIGN
do is error out and say "libpng does not support zero dimension images" however, this would be a statement based on one current version of libpng, and we cannot predict how the format will develop. The png_set_iHDR-function will error out if we pass bad data to it, so why bother in the

Re: [hackers] [sbase][PATCH] grep: remove = flag from readme

2016-04-03 Thread FRIGN
you could also try a setlocale(LC_ALL, "UTF-8"); in grep(1). Maybe that works. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [sbase][PATCH] grep: add -r

2016-04-03 Thread FRIGN
On Wed, 30 Mar 2016 05:23:08 +0200 Mattias Andrée <maand...@kth.se> wrote: > Unlike your usual grep -r, this implementation > uses breadth-first search. It usually finds > makes it find what you are looking for faster. Try working with recurse() in libutil. Cheers FRIG

Re: [hackers] [sbase][PATCH] grep: remove = flag from readme

2016-04-03 Thread FRIGN
t this highly depends on the libc you are using (and esp. the Regex engine). Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [libzahl] Fix example in comments

2016-03-07 Thread FRIGN
On Mon, 7 Mar 2016 14:08:04 +0200 Vasily Kolobkov <polezaivs...@openmailbox.org> wrote: > - = 40⋅30⋅10⁴ + (40⋅20 + 30⋅10)⋅10² + 10⋅20, but the middle is > + = 4⋅3⋅10⁴ + (40⋅20 + 30⋅10)⋅10² + 10⋅20, but the middle is 4000 * 3000 = 40 * 30 * 10^4 = 4 * 3 * 10^6. -- FRIGN <d...@frign.de>

Re: [hackers] [farbfeld] Fix 2 little things in jpg2ff(1) || FRIGN

2016-03-06 Thread FRIGN
= 0 here and use the form > without relational operator for logic or pointers values. You know how it is with style, but I respect your opinion on this matter as a senior programmer. I was wondering, don't you mean "argc != 0"? :) Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [libzahl] Add a number of man pages || Mattias Andrée

2016-02-29 Thread FRIGN
On Mon, 29 Feb 2016 15:34:42 +0100 (CET) g...@suckless.org wrote: > Add a number of man pages I swear to you, you are the only guy I know who writes the manuals before the code. -- FRIGN <d...@frign.de>

Re: [hackers] [sbase] Rever the strmem() addition and add a TODO element || FRIGN

2016-02-26 Thread FRIGN
This requires a strict tracking of string lengths. A short comment here: Of course I'll import memmem from OpenBSD into libutil, given it's a GNU extension. -- FRIGN <d...@frign.de>

Re: [hackers] dmenu][PATCH reversed

2016-02-20 Thread FRIGN
for your patch, but please resend it with git format-patch in a response to this thread! :) Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] Use argv0 instead of passing "slock:" to die every time || FRIGN

2016-02-15 Thread FRIGN
to just pass argv[0] to each call of die. But it is not. Would your approach be to just set argv0 as argv[0] and carry on without modifying argc, argv? I was surprised this idiomatic one-liner has received such opposition. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] No need for usage() || FRIGN

2016-02-15 Thread FRIGN
slock as second + further arguments. However, I respect your stances on this and will revert it, but also document -h in the manpage. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [slock] Use argv0 instead of passing "slock:" to die every time || FRIGN

2016-02-15 Thread FRIGN
se arg.h. We need argv0 here because I moved the prepending of the argv[0] into die(), and thus we need to store the argv0 in a global variable. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [ubase] mount: fix mount helper fs option handling || Brad Barden

2016-02-11 Thread FRIGN
se estrlcat() instead. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [farbfeld] Mandate "ProPhoto RGB" color space for farbfeld and handle ICC profiles || FRIGN

2016-01-17 Thread FRIGN
On Sun, 17 Jan 2016 10:10:19 + Dimitris Papastamos <s...@2f30.org> wrote: > Commit message reads like a diary. That's because it is a diary. :P -- FRIGN <d...@frign.de>

Re: [hackers] [PATCH] yellow italics everywhere is for colorblind people

2016-01-05 Thread FRIGN
re formatted, so that's how you can deduce a ml-etiquette easily. But feel free to send in a patch, so the newcomers know what it's about. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [PATCH] yellow italics everywhere is for colorblind people

2016-01-05 Thread FRIGN
your bloody mail. -- FRIGN <d...@frign.de>

Re: [hackers] [tabbed] Bump year. || Christoph Lohmann

2016-01-01 Thread FRIGN
On Fri, 1 Jan 2016 14:19:29 +0100 (CET) g...@suckless.org wrote: > - die("tabbed-"VERSION", © 2009-2014" > + die("tabbed-"VERSION", © 2009-2015" You probably mean 2016. -- FRIGN <d...@frign.de>

Re: [hackers] [sbase] chown: fix user:group option parsing

2015-12-21 Thread FRIGN
On Mon, 21 Dec 2015 19:05:17 + Dimitris Papastamos <s...@2f30.org> wrote: > uid_t, gid_t are typically unsigned, so the check needs to be > == -1 otherwise it will never be true. We both are wrong :P It can either be signed or unsigned. -- FRIGN <d...@frign.de>

Re: [hackers] [sbase] chown: fix user:group option parsing

2015-12-21 Thread FRIGN
On Mon, 21 Dec 2015 19:37:10 +0100 Quentin Rameau <quinq@fifth.space> wrote: > + if (uid == -1 && gid == -1) > + usage(); better use < 0 than -1 -- FRIGN <d...@frign.de>

Re: [hackers] [sbase] Cleanup usage() across sbase

2015-12-21 Thread FRIGN
"[[-k def] ...] [file ...]\n", argv0); Please make that a separate patch and change the manpage accordingly. > diff --git a/tar.c b/tar.c Ok. > diff --git a/touch.c b/touch.c Ok. > diff --git a/tr.c b/tr.c > > static void > usage(void) > { > - eprintf("usage: %s [-cCds] set1 [set2]\n", argv0); > + eprintf("usage: %s [-Ccds] set1 [set2]\n", argv0); Same here. Change the manpage. > diff --git a/xargs.c b/xargs.c Ok. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [sbase] Cleanup usage() across sbase

2015-12-21 Thread FRIGN
On Mon, 21 Dec 2015 18:36:28 +0100 Quentin Rameau <quinq@fifth.space> wrote: > Some tools didn't use argv0 for tool name, or usage() at all. Thanks, applied! :) http://git.2f30.org/sbase/commit/?id=fd70f2afbeb1cacc0d55aa47831c84f39ec80978 -- FRIGN <d...@frign.de>

Re: [hackers] [sent] [PATCH 2/2] replace farbfeld with libnetpbm

2015-12-13 Thread FRIGN
pply all the tools available in > the netpbm suite on a bulk of images, and there are quite some of them. I'll think about adding pbm2ff and ff2pbm to the farbfeld-utilities :P Then the crowd is happy and you can use the netpbm suite. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [sent] [PATCH 2/2] replace farbfeld with libnetpbm

2015-12-12 Thread FRIGN
easons why sent doesn't use PNG as an intermediate format. So, what is the reason? What does netpbm really _do_ better than farbfeld? And no, Roberto, writing an image in ed does not cut it. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [sent] [PATCH 2/2] replace farbfeld with libnetpbm

2015-12-10 Thread FRIGN
You've replaced the entire farbfeld parsing code in sent with the boilerplate "offered" by netpbm. Good job! A question for the diligent reader: Can you read in a netpbm file without first looking into the docs? Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [farbfeld] jpg2ff: fix segfault on JPG error

2015-12-08 Thread FRIGN
On Tue, 8 Dec 2015 11:28:17 +0100 Quentin Rameau <quinq+hackers@fifth.space> wrote: > We would try to free unitialized ff_row pointer in cleanup on jpeg > errors. thanks, applied! :) -- FRIGN <d...@frign.de>

Re: [hackers] [PATCH] [sent] Quick patch to replace png with farbfeld

2015-11-18 Thread FRIGN
m while working with the actual data. I again want to stress here that I've been dealing with libpng for almost 2 days now and I've still not found a satisfying general way to handle 16-Bit PNG's properly. The interface can be compared to the 6th circle of hell. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [PATCH] [sent] Quick patch to replace png with farbfeld

2015-11-17 Thread FRIGN
this direction are much appreciated. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [PATCH] [sent] Quick patch to replace png with farbfeld

2015-11-17 Thread FRIGN
worry about it in png2ff and ff2png, especially in regard to handling 64-Bit PNGs and other gems. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] [dmenu] paste fix

2015-10-04 Thread FRIGN
to be applied to mainline, where you want to make sure that historic accuracy with specific commit-hashes is guaranteed. In any other case, it doesn't bring much to the table. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] od: added support for different size values

2015-10-02 Thread FRIGN
day, when I've taken the exam. On thing left to discuss would be how to handle the printing. I'd heuristically set the format on the next major integral type. For instance, when we read in a 3 byte chunk, we want to take the next larger integral type (which is int32 with 4 bytes). Cheers FRIGN --

Re: [hackers] sbase: od: properly concatenate multiple file arguments

2015-10-02 Thread FRIGN
ightly better style than setting the variable directly at the declaration block. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] sbase: od: properly concatenate multiple file arguments

2015-10-02 Thread FRIGN
ocus one one single thing first, or you end up rewriting all your patches anyway. We first need to get the length-handling properly first. Cheers FRIGN -- FRIGN <d...@frign.de>

Re: [hackers] od: added options -b and -d; bug fix affecting size C

2015-10-02 Thread FRIGN
On Fri, 2 Oct 2015 03:07:00 -0400 Greg Reagle <greg.rea...@umbc.edu> wrote: Hey Greg, > Trying again. keep in mind that these flags are XSI-extensions, which we generally don't include in sbase. Let's discuss this on IRC, given the code-changes are not that drastic. Cheers FRIGN --

Re: [hackers] od: added options -b and -d; bug fix affecting size C

2015-10-02 Thread FRIGN
of these filenames is always interpreted as a filename, an application could always specify the address base format with the -A option." Do you really want that? Let's not touch the forbidden fruit. Cheers FRIGN [0]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html -- FRIGN <d...@frign.de>

Re: [hackers] created od

2015-09-29 Thread FRIGN
! This is a pretty important tool. :) I'll also take my time and comment on your patch adding the t-flag. Cheers FRIGN [0]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html -- FRIGN <d...@frign.de>

Re: [hackers] [sbase] Audit sort(1) and mark it as finished || FRIGN

2015-08-04 Thread FRIGN
file is unsorted, the return value is 1, as expected. For convenience reasons, check()'s warning now includes the filename. As a quick note, thanks to Dimitris we found out that Solaris also does it like that. We are not alone in this world. -- FRIGN d...@frign.de

[hackers] [st] [5 PATCHES] Code layout changes

2015-07-08 Thread FRIGN
you think about it! Cheers FRIGN -- FRIGN d...@frign.de From 584b615305589aa760d49e62cb7cf64d406d6653 Mon Sep 17 00:00:00 2001 From: FRIGN d...@frign.de Date: Wed, 8 Jul 2015 17:00:16 +0200 Subject: [PATCH 1/5] Remove insane *_FILENO and EXIT_* usage Any system having different assignments than

Re: [hackers] FILE vs fd

2015-06-13 Thread FRIGN
On Sat, 13 Jun 2015 10:06:04 +0530 Aditya Goturu aditya3...@gmail.com wrote: Is there any particular reason why I would use unix's fd and open() instead of ANSI's FILE struct and fopen()? Yes. -- FRIGN d...@frign.de

Re: [hackers] [sbase] [PATCH 1/2] join: get rid of strlen--fwrite barbarity

2015-06-06 Thread FRIGN
the length at hand is a good thing. On the other hand, join is completed feature-wise, so why not just store the length on the heap locally in the function and be done with it? It's not barbarous at all. Cheers FRIGN -- FRIGN d...@frign.de

  1   2   >