GNU bug report logs - #79194
Segfault with 0 byte symbol

Previous Next

To reply to this bug, email your comments to 79194 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: a aa <lgray3420 <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: Segfault with 0 byte symbol
Date: Thu, 7 Aug 2025 13:35:20 -0400

[Message part 1 (text/plain, inline)]

Hello,

how to reproduce:
cc main.c `pkg-config --libs --cflags guile-3.0` && ./a.out

incorrect behaviour:
The second parameter for scm_from_utf8_symboln should be how many bytes are
pointed to by the pointer however the pointer still gets read if the length
is zero. Being able to handle 0 byte strings is expected since replacing
the call from scm_from_utf8_symboln to scm_from_utf8_stringn will not have
a segfault and the documentation for this function does not mention being
unable to handle 0 byte strings.

version: 3.0.10 (built from source via gentoo ebuild)

config.guess:
x86_64-pc-linux-gnu

config.status:
--prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share
--disable-dependency-tracking --disable-silent-rules --disable-static
--docdir=/usr/share/doc/guile-3.0.10-r103
--htmldir=/usr/share/doc/guile-3.0.10-r103/html --with-sysroot=/
--libdir=/usr/lib64 --program-suffix=-3.0
--infodir=/usr/share/guile-data/3.0/info
--with-pkgconfigdir=/usr/share/guile-data/3.0/pkgconfig
--disable-error-on-warning --disable-rpath --disable-lto --enable-posix
--without-libgmp-prefix --without-libiconv-prefix --without-libintl-prefix
--without-libreadline-prefix --without-libunistring-prefix
--disable-guile-debug --disable-debug-malloc --enable-deprecated
--enable-jit --enable-networking --disable-nls --enable-regex
--with-threads build_alias=x86_64-pc-linux-gnu
host_alias=x86_64-pc-linux-gnu CC=gcc 'CFLAGS=-O2 -march=native -pipe
-std=gnu17' LDFLAGS=-fuse-ld=mold
PKG_CONFIG_PATH=/usr/share/guile-data/3.0/pkgconfig

[Message part 2 (text/html, inline)]

[main.c (text/plain, attachment)]

Message #8 received at 79194 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: a aa <lgray3420 <at> gmail.com>
Cc: 79194 <at> debbugs.gnu.org
Subject: Re: bug#79194: Segfault with 0 byte symbol
Date: Sun, 10 Aug 2025 16:34:33 +0200

Hi,

a aa <lgray3420 <at> gmail.com> writes:

> Hello,
>
> how to reproduce:
> cc main.c `pkg-config --libs --cflags guile-3.0` && ./a.out
>
> incorrect behaviour:
> The second parameter for scm_from_utf8_symboln should be how many bytes are
> pointed to by the pointer however the pointer still gets read if the length
> is zero. Being able to handle 0 byte strings is expected since replacing
> the call from scm_from_utf8_symboln to scm_from_utf8_stringn will not have
> a segfault and the documentation for this function does not mention being
> unable to handle 0 byte strings.

Well, the scm_from_utf8_symboln is just not documented at all, so I am
not sure how you have determined that the "documentation for this
function does no mention ...".  But let us ignore that for a moment.

You wrote "handle 0 byte *strings*" (emphasis mine).  That is not what
you are doing.  NULL is not a "0 byte string".  "" (almost) is.  Or a
char* can be.  But not NULL.

>
> [..]
>
> #include <libguile.h>
>
> void* inner_main(void*) {
>   SCM sym = scm_from_utf8_symboln(NULL, 0);

The line should be

    SCM sym = scm_from_utf8_symboln("", 0);

or

    const char zero_str[] = {};
    SCM sym = scm_from_utf8_symboln(zero_str, 0);

Both work fine.  You cannot just send a null pointer to a function that
is supposed to take a string and expect it to work.  So I do not think
it is valid to declare this to be an "incorrect behaviour", maybe
"unexpected" (by you) would be better description.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Message #11 received at 79194 <at> debbugs.gnu.org (full text, mbox):

From: a aa <lgray3420 <at> gmail.com>
To: 79194 <at> debbugs.gnu.org
Subject: Fwd: bug#79194: Segfault with 0 byte symbol
Date: Mon, 11 Aug 2025 23:41:38 +0000

[Message part 1 (text/plain, inline)]

---------- Forwarded message ---------
From: a aa <lgray3420 <at> gmail.com>
Date: Mon, Aug 11, 2025 at 11:40 PM
Subject: Re: bug#79194: Segfault with 0 byte symbol
To: Tomas Volf <~@wolfsden.cz>


Hello, Tomas <~@wolfsden.cz>

> You wrote "handle 0 byte *strings*" (emphasis mine).  That is not what
> you are doing.  NULL is not a "0 byte string".  "" (almost) is.  Or a
> char* can be.  But not NULL.

The string "" does not have 0 bytes in utf8. It has 1 byte for the null
terminator,
which is still reading out of bounds when providing 0 for its length.

I probably should have mentioned this in the first message, but I
experienced
this issue in rust which doesn't use null terminated strings so the example
wasn't
exactly accurate.

    rustc -lguile-3.0 main.rs

or if you don't have rust

    c++ main.cpp `pkg-config --cflags --libs guile-3.0`

> Both work fine.  You cannot just send a null pointer to a function that
> is supposed to take a string and expect it to work.  So I do not think
> it is valid to declare this to be an "incorrect behaviour", maybe
> "unexpected" (by you) would be better description.

The function does not take a string, it takes an array of utf8 codepoints
so the function
should not expect the pointer to have a null terminator.

On Sun, Aug 10, 2025 at 2:34 PM Tomas Volf <~@wolfsden.cz> wrote:

> Hi,
>
> a aa <lgray3420 <at> gmail.com> writes:
>
> > Hello,
> >
> > how to reproduce:
> > cc main.c `pkg-config --libs --cflags guile-3.0` && ./a.out
> >
> > incorrect behaviour:
> > The second parameter for scm_from_utf8_symboln should be how many bytes
> are
> > pointed to by the pointer however the pointer still gets read if the
> length
> > is zero. Being able to handle 0 byte strings is expected since replacing
> > the call from scm_from_utf8_symboln to scm_from_utf8_stringn will not
> have
> > a segfault and the documentation for this function does not mention being
> > unable to handle 0 byte strings.
>
> Well, the scm_from_utf8_symboln is just not documented at all, so I am
> not sure how you have determined that the "documentation for this
> function does no mention ...".  But let us ignore that for a moment.
>
> You wrote "handle 0 byte *strings*" (emphasis mine).  That is not what
> you are doing.  NULL is not a "0 byte string".  "" (almost) is.  Or a
> char* can be.  But not NULL.
>
> >
> > [..]
> >
> > #include <libguile.h>
> >
> > void* inner_main(void*) {
> >   SCM sym = scm_from_utf8_symboln(NULL, 0);
>
> The line should be
>
>     SCM sym = scm_from_utf8_symboln("", 0);
>
> or
>
>     const char zero_str[] = {};
>     SCM sym = scm_from_utf8_symboln(zero_str, 0);
>
> Both work fine.  You cannot just send a null pointer to a function that
> is supposed to take a string and expect it to work.  So I do not think
> it is valid to declare this to be an "incorrect behaviour", maybe
> "unexpected" (by you) would be better description.
>
> Tomas
>
> --
> There are only two hard things in Computer Science:
> cache invalidation, naming things and off-by-one errors.
>

[Message part 2 (text/html, inline)]

[main.rs (text/x-rust, attachment)]

[main.cpp (text/x-c-code, attachment)]

Message #16 received at 79194-done <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: 79194-done <at> debbugs.gnu.org
Subject: bug#79194: Segfault with 0 byte symbol
Date: Wed, 13 Aug 2025 14:07:17 +0200

Was fixed in 35f13806af653ef9ed656708dddcd1d2c8f8da9e.

Closing.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.