- Dillo-dev - lists.mailman3.com

Re: Avoid ctype(3) abuses

by Leonardo Taccari

Hello Rodrigo, Rodrigo Arias writes: > Hi, > > On Mon, Jan 12, 2026 at 11:05:17AM +0100, Leonardo Taccari wrote: > >Hello! > > > >Most ctype(3) functions usage abuses an undefined behavior of passing > >values outside integers outside EOF or the range representable as > >unsigned char. > > > >On NetBSD 11 and newer such incorrect behaviors crashes applications > >violating that and due that Dillo easily crash by just visiting, e.g. > ><https://www.NetBSD.org/>. > > > >For possible further information please give a look to > ><https://man.NetBSD.org/ctype.3#CAVEATS>. > > Interesting! > > >I have grep-ed all such uses and added the relevant cast to uchar_t > >similar to other ctype(3) calls already present and in that way I can > >also confirm that Dillo no longer crashes. > > Thanks for the patch and tests. > > We have wrappers that do just that for isspace() and isalnum() in > dlib/dlib.h: > > https://git.dillo-browser.org/dillo/tree/dlib/dlib.h?id=7c6ccebe61077902160… > > I would be inclined to add the extra wrappers there and use the > dIsspace, dIsalnum... macros instead of doing the explicit casting. > > Additionally, I think it would be safer to also switch all these ctype > macros to static inline functions so we cover accidental castings from > unexpected types with an error instead of a warning: > > static inline int dIsalnum(unsigned char c) { return isalnum(c); } > > Example: > > % cat foo.c > #include <ctype.h> > static inline int dIsalnum(unsigned char c) { return isalnum(c); } > #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) > > int main(void) > { > char *a = "a"; > dIsalnum(a); > dIsalnum_unsafe(a); > > return 0; > } > > % gcc foo.c -o foo > foo.c: In function ‘main’: > foo.c:8:18: error: passing argument 1 of ‘dIsalnum’ makes integer from pointer without a cast [-Wint-conversion] > 8 | dIsalnum(a); > | ^ > | | > | char * > foo.c:2:42: note: expected ‘unsigned char’ but argument is of type ‘char *’ > 2 | static inline int dIsalnum(unsigned char c) { return isalnum(c); } > | ~~~~~~~~~~~~~~^ > In file included from foo.c:1: > foo.c:3:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > 3 | #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) > | ^ > foo.c:9:9: note: in expansion of macro ‘dIsalnum_unsafe’ > 9 | dIsalnum_unsafe(a); > | ^~~~~~~~~~~~~~~ > [...] Good idea! I will then add possible missing d*() helper ctype(3) functions and adapt all direct ctype(3) users to switch to such d*() helper functions. I hope to be able to share possible patches for that in 48 hours or so! Thank you!

Jan. 12, 2026

Re: Include missing <stdlib.h> for calloc(3) and exit(3)

by Leonardo Taccari

Hello Rodrigo, Rodrigo Arias writes: > Hi, > > On Mon, Jan 12, 2026 at 11:04:07AM +0100, Leonardo Taccari wrote: > >Hello! > > > >When trying to build current HEAD of dillo in NetBSD the build fails > >with: > > > > [...] > > g++ ... -o dialog.o dialog.cc > > [...] > > dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > > 37 | #include "dlib/dlib.h" > > +++ |+#include <cstdlib> > > 38 | > > dialog.cc:192:11: error: 'exit' was not declared in this scope > > 192 | exit(1); > > | ^~~~ > > dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > > *** [dialog.o] Error code 1 > > [...] > > > >Including <stdlib.h> fixes that and the attached patch does that. > > Thanks!, merged in: > > https://git.dillo-browser.org/dillo/commit/?id=7c6ccebe61077902160798e5af46… > [...] Thank you very much for quickly applying it!

Jan. 12, 2026

Re: Avoid ctype(3) abuses

by Rodrigo Arias

Hi, On Mon, Jan 12, 2026 at 11:05:17AM +0100, Leonardo Taccari wrote: >Hello! > >Most ctype(3) functions usage abuses an undefined behavior of passing >values outside integers outside EOF or the range representable as >unsigned char. > >On NetBSD 11 and newer such incorrect behaviors crashes applications >violating that and due that Dillo easily crash by just visiting, e.g. ><https://www.NetBSD.org/>. > >For possible further information please give a look to ><https://man.NetBSD.org/ctype.3#CAVEATS>. Interesting! >I have grep-ed all such uses and added the relevant cast to uchar_t >similar to other ctype(3) calls already present and in that way I can >also confirm that Dillo no longer crashes. Thanks for the patch and tests. We have wrappers that do just that for isspace() and isalnum() in dlib/dlib.h: https://git.dillo-browser.org/dillo/tree/dlib/dlib.h?id=7c6ccebe61077902160… I would be inclined to add the extra wrappers there and use the dIsspace, dIsalnum... macros instead of doing the explicit casting. Additionally, I think it would be safer to also switch all these ctype macros to static inline functions so we cover accidental castings from unexpected types with an error instead of a warning: static inline int dIsalnum(unsigned char c) { return isalnum(c); } Example: % cat foo.c #include <ctype.h> static inline int dIsalnum(unsigned char c) { return isalnum(c); } #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) int main(void) { char *a = "a"; dIsalnum(a); dIsalnum_unsafe(a); return 0; } % gcc foo.c -o foo foo.c: In function ‘main’: foo.c:8:18: error: passing argument 1 of ‘dIsalnum’ makes integer from pointer without a cast [-Wint-conversion] 8 | dIsalnum(a); | ^ | | | char * foo.c:2:42: note: expected ‘unsigned char’ but argument is of type ‘char *’ 2 | static inline int dIsalnum(unsigned char c) { return isalnum(c); } | ~~~~~~~~~~~~~~^ In file included from foo.c:1: foo.c:3:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 3 | #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) | ^ foo.c:9:9: note: in expansion of macro ‘dIsalnum_unsafe’ 9 | dIsalnum_unsafe(a); | ^~~~~~~~~~~~~~~ Best, Rodrigo.

Jan. 12, 2026

Re: Include missing <stdlib.h> for calloc(3) and exit(3)

by Rodrigo Arias

Hi, On Mon, Jan 12, 2026 at 11:04:07AM +0100, Leonardo Taccari wrote: >Hello! > >When trying to build current HEAD of dillo in NetBSD the build fails >with: > > [...] > g++ ... -o dialog.o dialog.cc > [...] > dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > 37 | #include "dlib/dlib.h" > +++ |+#include <cstdlib> > 38 | > dialog.cc:192:11: error: 'exit' was not declared in this scope > 192 | exit(1); > | ^~~~ > dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > *** [dialog.o] Error code 1 > [...] > >Including <stdlib.h> fixes that and the attached patch does that. Thanks!, merged in: https://git.dillo-browser.org/dillo/commit/?id=7c6ccebe61077902160798e5af46… Best, Rodrigo

Jan. 12, 2026

Avoid ctype(3) abuses

by Leonardo Taccari

Hello! Most ctype(3) functions usage abuses an undefined behavior of passing values outside integers outside EOF or the range representable as unsigned char. On NetBSD 11 and newer such incorrect behaviors crashes applications violating that and due that Dillo easily crash by just visiting, e.g. <https://www.NetBSD.org/>. For possible further information please give a look to <https://man.NetBSD.org/ctype.3#CAVEATS>. I have grep-ed all such uses and added the relevant cast to uchar_t similar to other ctype(3) calls already present and in that way I can also confirm that Dillo no longer crashes. Attached in this email you can find a patch to address that. Thank you!

Jan. 12, 2026

Include missing <stdlib.h> for calloc(3) and exit(3)

by Leonardo Taccari

Hello! When trying to build current HEAD of dillo in NetBSD the build fails with: [...] g++ ... -o dialog.o dialog.cc [...] dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' 37 | #include "dlib/dlib.h" +++ |+#include <cstdlib> 38 | dialog.cc:192:11: error: 'exit' was not declared in this scope 192 | exit(1); | ^~~~ dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' *** [dialog.o] Error code 1 [...] Including <stdlib.h> fixes that and the attached patch does that. Thank you!

Jan. 12, 2026

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > I took a closer look and it seems that this patch doesn't address the > actual problem. The problem is that BSD inherits the non-blocking > behavior while Linux doesn't (POSIX doesn't seem to indicate what should > be done). We want the new_fd to work in blocking mode, so this patch > should fix it for BSD and Linux (otherwise let me know): > > ---8<--- > diff --git a/src/IO/control.c b/src/IO/control.c > index 6f677e52..0d11187e 100644 > --- a/src/IO/control.c > +++ b/src/IO/control.c > @@ -95,12 +95,30 @@ static void Control_read_cb(int fd, void *data) > > int new_fd = accept(control_fd, NULL, NULL); > if (new_fd < 0) { > - if (errno != EWOULDBLOCK) { > - MSG("accept failed: %s\n", strerror(errno)); > + if (errno == EAGAIN || errno == EWOULDBLOCK) { > + /* Nothing? */ > + return; > + } else { > + MSG_ERR("accept failed: %s\n", strerror(errno)); > exit(1); > } > - /* Nothing? */ > - return; > + } > + > + /* From accept(2) man page: > + * > + * On Linux, the new socket returned by accept() does not inherit > + * file status flags such as O_NONBLOCK and O_ASYNC from the > + * listening socket. This behavior differs from the canonical BSD > + * sockets implementation. Portable programs should not rely on > + * inheritance or noninheritance of file status flags and always > + * explicitly set all required flags on the socket returned from > + * accept(). > + * > + * So, disable O_NONBLOCK flag explicitly. > + */ > + if (fcntl(new_fd, F_SETFL, 0) == -1) { > + MSG_ERR("control socket fcntl failed: %s\n", strerror(errno)); > + exit(1); > } > > ssize_t r; > ---8<--- Tested & works fine here :)

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > > PS. Any chance of adding an option to reload dillorc prefs too? :) > > That would be doable, but I'm not sure if we can just re-parse all > settings as-is without propagating the new values to other parts of > Dillo which might have made a copy. > > Which use case do you have in mind? For the user agent rotation? That was my initial use-case, but I also think that being able to change things like fonts and colors without having to restart dillo could be more useful for average users. For example switching between a light and dark color mode, or switching between regular fonts and CJK, etc. Thanks! Alex

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Tested & works fine here :) Thanks for testing, I merged it. Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > > Right away dillo exits and the console message shows this: > > > > ** ERROR **: Control_read_cb Resource temporarily unavailable > > Hmm, I don't think I'm catching all possible errors from that socket. > Maybe this patch can help: > > ---8<--- > diff --git a/src/IO/control.c b/src/IO/control.c > index 6f677e52..c6cd15bf 100644 > --- a/src/IO/control.c > +++ b/src/IO/control.c > @@ -110,7 +110,7 @@ static void Control_read_cb(int fd, void *data) > r = read(new_fd, buf, 1); > _MSG("read = %zd\n", r); > if (r < 0) { > - if (errno == EINTR) { > + if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) { > continue; > } else { > MSG_ERR("Control_read_cb %s\n", dStrerror(errno)); > ---8<--- > > Let me know if that makes it work. Looks to be working now! Thanks for this very cool new feature, BTW! Regards, Alex PS. Any chance of adding an option to reload dillorc prefs too? :)

Dec. 20, 2025