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--