[dev] [st] Two flaws with ISO 8613-6 colors
The relevant material is on page 49 of the standard. The first of the two issues is the least concerning: ``A parameter substring for values 38 or 48 may be divided by one or more separators (03/10) into parameter elements''... Due to the ``may'', it seems fair to interpret this as allowing either semicolons or colons to be used to separate the parameters. However, st only interprets such with the semicolons, which is a flaw. The second flaw is more severe and is something I'm filing bug reports with regards to many terminal emulators for: ``If the first parameter element has the value 2, 3, or 4, the second parameter element specifies a colour space identifier referring to a colour space definition in the document profile.'' The colour space identifier isn't discussed further in the standard, so it's reasonable to leave it at its default value. However, st and other terminals entirely ignore this parameter and interpret it as the third parameter and all others are shifted as well. That is to inform you that this is an example of a correct sequence to form a red, assuming 255 is a permitted value: CSI 38;2::255:0:0m However, st and others require this incorrect form to be sent, instead (ignoring here that st doesn't properly parse with colons used): CSI 38;2:255:0:0m Otherwise, the color may be misinterpreted as, say, a green or the color not changed at all, varying. The flaws are now clear. Both of these flaws should be trivial to correct, but I'm not familiar enough with both the st source and the suckless coding standards to provide a patch quickly and instead simply report the issue to you. It seems that a quick hack in csiparse(), if it's passed 38 as the first argument, with later checking that the control function was SGR and whatnot would be a good way to do this. It seems the second issue lies in tdefcolor() and could be corrected by simply changing the indexes for the r, g, and b values in the first case of the switch statement and also correcting the parameter number check.
[dev] [st] Two flaws with ISO 8613-6 colors, continued
The following diff corrects the flaws I've mentioned earlier with
regards to ISO 8613-6 colors; to repeat, these flaws include not
permitting colons to be used as seperators and incorrectly parsing RGB
color parameters; only six lines are changed and changed very little at
that, but I'll still release these six changed lines to the public
domain, for simplicity:
diff -c /home/programmer/st-0.8.1/st.c\~ /home/programmer/st-0.8.1/st.c
*** /home/programmer/st-0.8.1/st.c~ Tue Mar 20 15:29:59 2018
--- /home/programmer/st-0.8.1/st.c Fri Jul 13 19:32:43 2018
***
*** 1157,1163
v = -1;
csiescseq.arg[csiescseq.narg++] = v;
p = np;
! if (*p != ';' || csiescseq.narg == ESC_ARG_SIZ)
break;
p++;
}
--- 1157,1163
v = -1;
csiescseq.arg[csiescseq.narg++] = v;
p = np;
! if (*p != ';' || *p != ':' || csiescseq.narg == ESC_ARG_SIZ)
break;
p++;
}
***
*** 1311,1326
switch (attr[*npar + 1]) {
case 2: /* direct color in RGB space */
! if (*npar + 4 >= l) {
fprintf(stderr,
"erresc(38): Incorrect number of parameters
(%d)\n",
*npar);
break;
}
! r = attr[*npar + 2];
! g = attr[*npar + 3];
! b = attr[*npar + 4];
! *npar += 4;
if (!BETWEEN(r, 0, 255) || !BETWEEN(g, 0, 255) || !BETWEEN(b,
0, 255))
fprintf(stderr, "erresc: bad rgb color (%u,%u,%u)\n",
r, g, b);
--- 1311,1326
switch (attr[*npar + 1]) {
case 2: /* direct color in RGB space */
! if (*npar + 5 >= l) {
fprintf(stderr,
"erresc(38): Incorrect number of parameters
(%d)\n",
*npar);
break;
}
! r = attr[*npar + 3];
! g = attr[*npar + 4];
! b = attr[*npar + 5];
! *npar += 5;
if (!BETWEEN(r, 0, 255) || !BETWEEN(g, 0, 255) || !BETWEEN(b,
0, 255))
fprintf(stderr, "erresc: bad rgb color (%u,%u,%u)\n",
r, g, b);
Diff finished. Fri Jul 13 19:33:32 2018
[dev] [st] Two flaws with ISO 8613-6 colors, proper
Follows is the proper form of the st patch submitted earlier,
st-fix_8613_colors-0.8.1.diff:
diff -up st-0.8.1/st.c st-0.8.1-changed/st.c
--- st-0.8.1/st.c Tue Mar 20 15:29:59 2018
+++ st-0.8.1-changed/st.c Wed Jul 25 13:55:16 2018
@@ -1157,7 +1157,7 @@ csiparse(void)
v = -1;
csiescseq.arg[csiescseq.narg++] = v;
p = np;
- if (*p != ';' || csiescseq.narg == ESC_ARG_SIZ)
+ if (*p != ';' || *p != ':' || csiescseq.narg == ESC_ARG_SIZ)
break;
p++;
}
@@ -1311,16 +1311,16 @@ tdefcolor(int *attr, int *npar, int l)
switch (attr[*npar + 1]) {
case 2: /* direct color in RGB space */
- if (*npar + 4 >= l) {
+ if (*npar + 5 >= l) {
fprintf(stderr,
"erresc(38): Incorrect number of parameters
(%d)\n",
*npar);
break;
}
- r = attr[*npar + 2];
- g = attr[*npar + 3];
- b = attr[*npar + 4];
- *npar += 4;
+ r = attr[*npar + 3];
+ g = attr[*npar + 4];
+ b = attr[*npar + 5];
+ *npar += 5;
if (!BETWEEN(r, 0, 255) || !BETWEEN(g, 0, 255) || !BETWEEN(b,
0, 255))
fprintf(stderr, "erresc: bad rgb color (%u,%u,%u)\n",
r, g, b);
Re: [dev] [st] Two flaws with ISO 8613-6 colors, proper
On Thu, 26 Jul 2018 09:31:39 +0200, Hiltjo Posthuma wrote: > I'm curious, is there a specific program you use where this bug is noticable? I noticed this bug present in every terminal emulator I've tested; I've been writing a terminal abstraction library, as the language I'm using lacks a good one. I've been going around trying to have this bug corrected so I can start sending the correct sequence and st is one of my first stops, in part because it's easy to contribute to the code here and the code is simple to understand. I spent all of a few minutes looking until I found where I needed to change. I'm interested in, at some point, trying to organize some manner of meeting where terminal developers can define some psuedo-standards for certain things, rather than ``do whatever xterm does''. Do you think that's something that st would like to be a part of? I'm mostly concerned with making function key and mouse sequences sane. ECMA-48 defines FUNCTION KEY, but xterm has an insane table of control sequences it uses, instead.
[dev] [st] Two flaws with ISO 8613-6 colors, checking
I'm curious about the state of my patches. I've not seen them added to the current version of st. Am I simply being impatient or is there something wrong with them? Also, my last questions don't seem to have been responded to. Are there any thoughts on them now?
Re: [dev] [st] Two flaws with ISO 8613-6 colors, checking
>Can you point me to the specific part in the specification which would >indicate this is a bug vs >the standard? The relevant material is on page 49 of the standard. You may find the standard here: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.416-199303-I!!PDF-E&type=items ``A parameter substring for values 38 or 48 may be divided by one or more separators (03/10) into parameter elements''... Due to the ``may'', it seems fair to interpret this as allowing either semicolons or colons to be used to separate the parameters. However, st only interprets such with the semicolons, which is a flaw. ``If the first parameter element has the value 2, 3, or 4, the second parameter element specifies a colour space identifier referring to a colour space definition in the document profile.'' The colour space identifier isn't discussed further in the standard, so it's reasonable to leave it at its default value. However, st and other terminals entirely ignore this parameter and interpret it as the third parameter and all others are shifted as well. >A reproducable small test program in shell would be nice also to compare to >other terminal emulators. Here is an example of a correct sequence to form a red, assuming 255 is a permitted value: CSI 38;2::255:0:0m You can express this with the following: printf '\x1b[38;2::255:0:0m' St and others require this incorrect form to be sent, instead (ignoring here that st doesn't properly parse with colons used): CSI 38;2:255:0:0m You can express this with the following: printf '\x1b[38;2:255:0:0m'
Re: [dev] AfD discussion of dwm Wikipedia article
As you said, it is the first hit and it points to suckless.org i could not care less about what an article on wikipedia says about dwm, if a potential user reads the article, as long as the reference link points to suckless.org its cool with me. "...and nothing of value was lost" On Wed, Feb 24, 2010 at 08:08:32AM +, Anselm R Garbe wrote: > Hi, > > someone pointed me to this: > > http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Dwm#Dwm > > I wouldn't recommend to join that discussion there, such appeals > usually lead to the deletion. But perhaps someone has more links to > second party sources that might convince them to keep the article. > > As you'll see, I'm neutral to the deletion, we got a wiki ourselves > and first hit in Google is dwm.suckless.org when googling for dwm. > That's most important ;) > > Cheers, > Anselm >
Re: [dev] GSoC 2010
I think this is a good project idea, and it would prove more than useful also im looking forward to the simple port scanner, these project ideas have caugth my attention. On Wed, Mar 03, 2010 at 03:41:12PM +0100, Nicolai Waniek wrote: > On 03/03/2010 02:46 PM, Peter John Hartman wrote: > > I agree about the issue trackers + the mail integration. A small > > suggestion: none of the issue/bug tracking systems do collaboration very > > well either. What I mean by "collaboration" is the capacity to pass a > > single document back and forth with several "notes" appended to it. a > > giant > > You might think on a distributed bug-tracking system similar to a list of > bug-reports inside a git system with the possibility to create new bugreports > "on the fly" when the mail-server receives a specific mail (you somehow have > to > define a standar like "SHORT, FROM, DESCRIPTION, STEPS" and so on). > There should be a 'central' (though not required) bug-tracking server for all > those coming with bugs on you project-website. there, the current bug list and > state is a available and an interface to add new bugs. then you could place > some sort of hooks into your bugtracker (bt) configuration: > bt/.config/new-> send mail to mail-adress with new bug > then you can manage bug-notification via mailing lists. For users that don't > want to use the website, you could listen on mails in a specific form/with a > specific header to pass it directly to bt parsing it. if the parsing fails, > automagically send a mail back to the composer with annotation where it > failed, > if successfull, send back a success-mail. > > usage could be like (in a distributed way): > $ cd bugs/projectname > bugs/projectname $ bt pull # pulls all new bugreports from server > 7 new bugreports > bugs/projectname $ >51 unresolved bugs > 123 pending bugs > > where 'pending' means that their state is in "needs check if the bugfix works > or not, waiting for approval" or something like that. > > If you want to make comments to a file, make them and afterwards a > bugs/projectname $ bt commit -m "some annotation" > bugs/projectname $ bt send # send new file to whole mailinglist > bugs/projectname $ bt send some.u...@host.tld # send your changeset just to a > specific user > > would do the rest. > > something like that. Didn't think too carefully on it. >
[dev] [dwmstatus] barM.c security and enhancement patch.
I noticed that barM.c obtained from here
dwm.suckless.org/dwmstatus/barM.c was using fixed buffers without
concern for the length of said buffer creating the possibility of a
buffer overflow.
I have also declared global variables and functions static because
there is only one file. This may lead to slightly better generated
code.
I have also made the program loop in order to eliminate the bash loop.
There is no advantage to looping in bash.
Finally I have made slight improvements to some of the comments.
--- barM.c
+++ barM.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014,2015 levi0x0
+ * Copyright (C) 2014,2015 levi0x0 with enhancements by ProgrammerNerd
*
* barM (bar_monitor or BarMonitor) is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -10,7 +10,7 @@
*
* Read main() to configure your new status Bar.
*
- * compile: gcc -o barM barM.c -lX11
+ * compile: gcc -o barM barM.c -O2 -s -lX11
*
* mv barM /usr/local/bin/
*/
@@ -25,36 +25,23 @@
/*
* Put this in your .xinitrc file:
*
- * while true;do
- * $(barM)
- * done &
+ * barM&
*
*/
-#define VERSION "0.11"
+#define VERSION "0.12"
#define TIME_FORMAT "(%H:%M) (%d-%m-%Y)"
#define MAXSTR 1024
-static char status[MAXSTR];
-/*append here your commands*/
-char *commands[] = {"uname",
+/*Append here your commands.*/
+static const char *const commands[] = {"uname",
"free -mh | awk 'NR==2{print $3\"/\"$2}'"
};
-/* will append the buffer to status*/
-void sprint(char *format, ...) {
-va_list li;
-static char s[MAXSTR];
-va_start(li, format);
-vsprintf(s, format, li);
-va_end(li);
-strcat(status, s);
-}
-
-/* returen the date*/
-char * date(void) {
+/* Returns the date*/
+static char * date(void) {
static char date[MAXSTR];
time_t now = time(0);
@@ -64,8 +51,10 @@
}
-/* open a pipe for a new coomand and return the output*/
-char * spawn(char *c) {
+/* Opens a pipe for a new command and return the output.*/
+#define xstr(s) str(s)
+#define str(s) #s
+static char * spawn(const char *c) {
FILE *proc;
static char buffer[MAXSTR];
@@ -74,14 +63,14 @@
exit(1);;
}
-fscanf(proc, "%[^\n]", buffer);
+fscanf(proc, "%"xstr(MAXSTR)"[^\n]", buffer);
pclose(proc);
return buffer;
}
-void XSetRoot(char *name) {
+static void XSetRoot(const char *name) {
Display *display;
if (( display = XOpenDisplay(0x0)) == NULL ) {
@@ -95,17 +84,23 @@
XCloseDisplay(display);
}
-int main(int argc, char **argv) {
-int i = 0;
-for(i = 0; commands[i]; i++ ) {
-sprint("(%s) ", spawn(commands[i]));
+int main(int argc, char **argv) {
+char status[MAXSTR];
+for(;;){
+int left=sizeof(status),i;
+char*sta=status;
+for(i = 0; i=(status+MAXSTR))/*When snprintf has to resort to truncating a string it will return the length as if it were not truncated.*/
+goto skipDate;
+}
+strncpy(sta,date(),left);
+skipDate:
+status[MAXSTR-1]=0;
+XSetRoot(status);
+sleep(1);
}
-
-sprint("%s", date());
-XSetRoot(status);
-
-/* sleep by default you dont need to add it to your bash*/
-sleep(1);
-
return 0;
}
Re: [dev] [dwmstatus] barM.c security and enhancement patch.
I was not aware of this. I have pushed my changes to the wiki. Thank you for telling me about this. On Sun, Jun 14, 2015 at 2:45 AM, Christoph Lohmann <2...@r-36.net> wrote: > Greetings. > > On Sun, 14 Jun 2015 09:45:31 +0200 Programmer Nerd > wrote: >> I noticed that barM.c obtained from here >> dwm.suckless.org/dwmstatus/barM.c was using fixed buffers without >> concern for the length of said buffer creating the possibility of a >> buffer overflow. >> >> I have also declared global variables and functions static because >> there is only one file. This may lead to slightly better generated >> code. >> >> I have also made the program loop in order to eliminate the bash loop. >> There is no advantage to looping in bash. >> >> Finally I have made slight improvements to some of the comments. > > You can push changes to the wiki directly: [0] > > > Sincerely, > > Christoph Lohmann > > [0] http://suckless.org/wiki > >
