bug#79483: Segmentation fault: set-car! in compiled code

[email protected] Tue, 23 Sep 2025 06:22:45 +0200
Newsgroups gmane.lisp.guile.bugs
Message-ID <[email protected]>
--gCXt3ZuUOf3y3BW5
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 22, 2025 at 09:27:54PM +0200, Tomas Volf wrote:
> <[email protected]> writes:
>=20
> > On Mon, Sep 22, 2025 at 12:50:57AM +0300, var-vniiaes--- via Bug report=
s for GUILE, GNU's Ubiquitous Extension Language wrote:
> >>=20
> >> Hello,
> >> =C2=A0
> >> Execution of =C2=A0 (set-car! '(0) 1) =C2=A0 *in compiled code* =C2=A0=
leads to segfault:
> >
> > First of all: you shouldn't be doing that :)
> >
> > You are mutating a constant. I don't know what the Scheme specification=
 says
> > to it (if at all).
>=20
> --8<---------------cut here---------------start------------->8---
> As noted in section 3.4, it is an error to attempt to alter
> a constant (i.e. the value of a literal expression) using a
> mutation procedure like set-car! or string-set!
> --8<---------------cut here---------------end--------------->8---
>=20
> > The other question is whether Guile should/could catch that and signal =
an
> > error instead.
>=20
> I believe it should not.

This is ambiguous, but from the context below I think you mean Guile
should catch it. I agree :-)

> Memory-safe languages (and, Guile is supposed
> to be one) should never segfault but instead terminate with a sensible
> error.  I realize that 1.3.2 allows to "fail catastrophically", which
> segfault probably qualifies as, but I believe we should do better.

Definitely -- the question is whether Guile wants to rely on the
OS/runtime to catch an out-of-bounds access (or more probably here
an access to a region marked read-onls) or catch it itself.

Cheers
--=20
tom=C3=A1s

--gCXt3ZuUOf3y3BW5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaNIghwAKCRAFyCz1etHa
Rs2JAJ9CMYnzfzNwOSjYydPZ04ygIS5UDQCfcOBziW5gdQCK19KtHLc326mje24=
=Q82r
-----END PGP SIGNATURE-----

--gCXt3ZuUOf3y3BW5--