Re: [dev] Re: [st] [PATCH] Avoid buffer overflows in the case of key-mapped strings.

From: FRIGN <dev_AT_frign.de>
Date: Thu, 10 Oct 2013 20:36:32 +0200

On Thu, 10 Oct 2013 21:06:33 +0200
Christoph Lohmann <20h_AT_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 the
> task. It’s impossible.
>
> For the special case: What’s the sense in sending a NULL string on a
> shortcut? You are supposed to get a strange error you can only solve by
> thinking when you do that. Roberto is right on this. Will we do boundary
> checks on the other variables too?
>
>
> Sincerely,
>
> Christoph Lohmann
>
>

Hey Christoph,

in at least one point, I have to disagree: The need to understand a
program's technology may be a new concept, but will be more and more
common in the future. In my opinion, we as the suckless-developers are
shaping the way for the following generations, who will know the matter
(unless they have been dumbed-down by Windows, Mac OS or Ubuntu before).

I agree with you on the boundary check: It's unnecessary and somewhat
arbitrary. If operators get segfaults due to _compile time_ configure
errors, they usually should know what it's about by debugging it. We
really have to differenciate between compile time- and run
time-configuration. For the former, run time-checks don't make much
sense.

In addition, the end-user, who will most likely not tweak the settings
too much anyway (and pass an empty string), factually doesn't demand
these kind of checks and would fall back to default configs in case of
problems (which is done easily, as st is not mission-critical software
in the first place and there are people to ask on the Internet who know
what they're doing).

Keep the software simple and omit this stuff. That's my opinion.

Cheers

FRIGN

-- 
FRIGN <dev_AT_frign.de>
Received on Thu Oct 10 2013 - 20:36:32 CEST

This archive was generated by hypermail 2.3.0 : Thu Oct 10 2013 - 22:36:19 CEST