In my opinion, the lock (slock) shall be remain very light based a
very minimum of x11, in other words just on the x11 minimum of x11
layer functions/libs
slock might be a minimal x11 lock, without any additional features. Is
actually getpwuid() really needed? slock function might be to simply
On Wed, Nov 13, 2013 at 09:32:44PM +0100, patrick295767 patrick295767 wrote:
> Hi,
>
> Slock is a nice application. However I would go on simpler
> even to avoid the suid/sgid check.
On a side note for the other check on getpwuid() we should really
be setting errno to zero before the call and che
On 11/13/13, sin wrote:
> On Wed, Nov 13, 2013 at 09:32:44PM +0100, patrick295767 patrick295767
> wrote:
>> even to avoid the suid/sgid check.
>
> So we should not check for errors anymore? That check is
> perfectly valid.
>
Yeah, i would agree with sin here, it makes sense to tell the user
wha
On Wed, Nov 13, 2013 at 09:32:44PM +0100, patrick295767 patrick295767 wrote:
> Hi,
>
> Slock is a nice application. However I would go on simpler
> even to avoid the suid/sgid check.
So we should not check for errors anymore? That check is
perfectly valid.
bye,
sin
Hi,
Slock is a nice application. However I would go on simpler
even to avoid the suid/sgid check.
In my opinion, it could/should stick to a minimum.
/ramdisk/slock-1.1$ make
slock build options:
CFLAGS = -std=c99 -pedantic -Wall -Os -I. -I/usr/include
-I/usr/X11R6/include -DVERSION="1.1" -DHA
2013/11/13 Thorsten Glaser :
> Roberto E. Vargas Caballero dixit:
>
>>long, because long is at least 32 bits for sure, but int can be only 16
>
> On POSIX, int is a minimum 32 bit data type.
Also, stdint.h.
--
At your service,
Alexander S.
Roberto E. Vargas Caballero dixit:
>long, because long is at least 32 bits for sure, but int can be only 16
On POSIX, int is a minimum 32 bit data type.
bye,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf
On Wed, Nov 13, 2013 at 11:57:57AM +0100, Johannes Hofmann wrote:
> Hi,
>
> why is a type that can have a different number of bits on 32/64 bit
> systems used for Glyph.fg and Glyph.bg?
> Wouldn't unsigned int be enough?
and int can not be different? If we want be standard complaint it must be
lo
Hi,
why is a type that can have a different number of bits on 32/64 bit
systems used for Glyph.fg and Glyph.bg?
Wouldn't unsigned int be enough?
Regards,
Johannes
