diff --git a/pep-0682.rst b/pep-0682.rst
index 98d027262..03801e854 100644
--- a/pep-0682.rst
+++ b/pep-0682.rst
@@ -111,8 +111,13 @@ std::format()`_.  While the proposal was withdrawn for C++20, a consensus
 proposal is promised for C++23.  (The original `feature request`_ prompting
 this PEP was argued without knowledge of the C++ proposal.)
 
+When Rust developers debated whether to suppress negative zero in ``print``
+output, they took a small `survey of other languages`_.  Notably, it didn't
+mention any language providing an option for negative zero handling.
+
 .. _`proposed for C++ std::format()`: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1496r2.pdf
 .. _`feature request`: https://bugs.python.org/issue45995
+.. _`survey of other languages`: https://github.com/rust-lang/rfcs/issues/1074#issuecomment-718243936
 
 
 Specification
@@ -125,7 +130,8 @@ An optional, literal ``z`` is added to the
 
     [[fill]align][sign][z][#][0][width][grouping_option][.precision][type]
 
-where ``z`` is allowed for numerical types other than integer.  Support for
+where ``z`` is allowed for floating-point presentation types (``f``, ``g``,
+etc.,  as defined by the format specification documentation).  Support for
 ``z`` is provided by the ``.__format__()`` method of each numeric type,
 allowing the specifier to be used in f-strings, built-in ``format()``, and
 ``str.format()``.  The %-formatting style will not support the new option.
@@ -159,6 +165,12 @@ the new option, %-formatting cannot.  There is already precedent for not
 extending %-formatting with new options, as was the case for the
 ``,`` option (:pep:`378`).
 
+C99 ``printf`` already uses the ``z`` option character for another
+purpose:  qualifying the unsigned type (``u``) to match the length of
+``size_t``.  However, since the signed zero option specifically disallows
+``z`` for integer presentation types, it's possible to disambiguate the two
+uses, should C want to adopt this new option.
+
 
 Backwards Compatibility
 =======================