It seems that this issue was introduced in 624dd8a17a.

With the help of GDB I found the machine code causes segfault

Tested on 3.0.11 and 3.0.10, 3.0.9 still works.

$ export GUILE_JIT_THRESHOLD=1

$ guile

GNU Guile 3.0.11
Copyright (C) 1995-2024 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (format #t "~." 'a)
Segmentation fault

Expected behavior

$ export GUILE_JIT_THRESHOLD=-1

$ guile

GNU Guile 3.0.11
Copyright (C) 1995-2024 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (format #t "~." 'a)

FORMAT: error with call: (format #t "~.<===" ===>a )
        unknown control character `.'
FORMAT: INTERNAL ERROR IN FORMAT-ERROR!
        destination: #t
        format string: "~."
        format args: (a)
        error args:  (#f "error in format" () #f)
ice-9/boot-9.scm:1705:22: In procedure raise-exception:
error in format

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> 

Noted that in R6RS, a vector is composite syntax object like pair while a bytevector is considered as an atom.

Noted that, +nan.0 and +inf.0 don't support SFDL[E] suffix, so there's no portable way to express NaN and Infinity in different precision.

I guess the reason that R6RS uses a stricter semantic is they also specified equal-hash. The semantics of this procedure are closely related to the semantics of equal? itself.

@jjba23 wrote in #208 (comment):

I want to show an example how the nondeterminism characteristic of "unspecified value" provides flexibility for implementation to optimize for performance.

WebAssembly spec add following rules to relax the requirement of IEEE on floating point operations.

Noted that, many Scheme implements eval by "invoking AOT compiler at runtime", rather than a true JIT compiler. Therefore, they usually don't support embedding the references of run-time values.

@jobol wrote in #368 (comment):

I think the identifier started with digits are reserved for implementation-defined enhanced numeric literal syntax, such as underscore in number, and units system.

@phm wrote in #11 (comment):

@johnwcowan wrote in #11 (comment):

This is itself both ambiguous (How many replacement characters are inserted if two initial bytes erroneously follow one another? How many if multiple continuation bytes appear without an initial byte? How many bytes are 'ignored' in those cases?)

If we are in favor of deterministic behavior, the subsection "U+FFFD Substitution of Maximal Subparts" of section 3.9 "Unicoding Encoding Forms" in Unicode Core Specification wrote that

An increasing number of implementations are adopting the handling of ill-formed subsequences as specified in the W3C standard for encoding to achieve consistent U+FFFD replacements. See:

• http://www.w3.org/TR/encoding/

In particular, the decoder of UTF-8 is described in https://encoding.spec.whatwg.org/#utf-8-decoder

BTW, Unicode Technical Committee had proposed to change the guidance for the preferred numbers of replacement character, but they finally retract those changes. It was this post that described the status quo of the insertion of replacement characters and prompted the Unicode Technical Committee to retract those decisions

Here's a short survey about subnormal numbers in practice.

Thanks! I ought to check the errata list of R7RS but forget to do so...

The Appendix B "Standard Feature Identifiers" of R7RS-small specified exact-closed feature as "All algebraic operations except / produce exact values given exact inputs."

The definition of "algebraic operations" is unclear. For example, sqrt, which calculate the square root of a number, should be considered as an "algebraic operation" in the sense of math. However, it's allowed to return inexact result on exact inputs.

Comparing with R6RS, the latter give a explicit list of operations that propagate the exactness in 11.7.1 "Propagation of exactness and inexactness".

On the 2026-06-08 meeting, WG basically agree that implementation must support NaN, +-Infinity, +-0.0 for floating point numbers.

R6RS Standard Libraries 2.6 "Operation on strings"

If an invalid or incomplete character encoding is encountered, then the replacement character U+FFFD is appended to the string being generated, an appropriate number of bytes are ignored, and decoding continues with the following bytes.

Current implementation will raise decode-error exception on invalid character instead of replacing with U+FFFD.

(use-modules (rnrs) ((ice-9 iconv) #:prefix iconv:))

(utf8->string #u8(172 27 10 83 34))
;; Throw to key `decoding-error' with args `("scm_from_utf8_stringn" "input locale conversion error" 0 #vu8(172 27 10 83 34))'.

(define (real-utf8->string bv) (iconv:bytevector->string bv "UTF-8" 'substitute))
(real-utf8->string #u8(172 27 10 83 34))
;; => "�\x1b\nS\""

I post this to the wrong place, sorry.

R6RS Standard Libraries 2.6 "Operation on strings"

If an invalid or incomplete character encoding is encountered, then the replacement character U+FFFD is appended to the string being generated, an appropriate number of bytes are ignored, and decoding continues with the following bytes.

Current implementation will raise decode-error exception on invalid character instead of replacing with U+FFFD.

(use-modules (rnrs) ((ice-9 iconv) #:prefix iconv:))

(utf8->string #u8(172 27 10 83 34))
;; Throw to key `decoding-error' with args `("scm_from_utf8_stringn" "input locale conversion error" 0 #vu8(172 27 10 83 34))'.

(define (real-utf8->string bv) (iconv:bytevector->string bv "UTF-8" 'substitute))
(real-utf8->string #u8(172 27 10 83 34))

;; => "�\x1b\nS\""

I think this is the same kind error of #92

Also tested on 3.0.9.

Not be associative with container content

In past, Guile use bitwise-exclusive-or (XOR) to combine hash for
containers for structures from their the hash of their child element.

However, XOR is not a good combiner due to its associativity and
commutativity. Associativity would lead '((A . B) . C) and '(A . (B .
C)) to the same hash, and commutativity would lead '(A . B)
and '(B . A) to the same hash.

Another pitfall of XOR is, the hash of '(T . T) will be zero for all T
because x ^ x == 0.

This patch introduce a new hash combiner suggested in
https://stackoverflow.com/a/27952689 to solve the problems above.

• libguile/hash.c (combine_hash): New function.
  (scm_i_struct_hash): Use 'combine_hash' to combine hashes.
  (scm_raw_ihash): Ditto.