Signed-off-by: Rosie K Languet <rkl@rosiesworkshop.net>
---
This updates the flexible literal promotion algorithm to match current harec
behavior in promoting signed flexible literals to unsigned integer types.
language/expressions.tex | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/language/expressions.tex b/language/expressions.tex
index 0d47f53..dcbc110 100644
--- a/language/expressions.tex+++ b/language/expressions.tex
@@ -2809,11 +2809,15 @@ which shall be the result of the promotion.
\specsubitem
If one operand is a flexible integer and the other is a non-flexible type, the
-promotion shall succeed only if the non-flexible type is an integer type, and-the minimum and maximum value fields of the flexible integer are representable-within the non-flexible integer type without any data loss. If the promotion-succeeds, the flexible integer shall be lowered to the non-flexible integer-type, which shall be the result of the promotion.+promotion shall succeed only if the non-flexible type is an integer type and if+the maximum value field of the flexible integer is representable within the+integer type without any data loss. If the integer type is signed, the promotion+shall succeed only if the minimum value field is also so representable. If the+integer type is unsigned and the flexible integer is negative, it shall be first+promoted to the corresponding (equal-width) signed integer type, and then+bit-cast to the unsigned type. If the promotion succeeds, the flexible integer+shall be lowered to the non-flexible integer type, which shall be the result of+the promotion.\specsubitem
If one operand is a flexible rune, the promotion shall succeed if the other type
--
2.47.1
I think Assignability rules also doesn't describe the current situation vis-à-vis
negative values and unsigned types... Am I missing something?
January 11, 2025 at 2:18 PM, "Rosie K Languet" <rkl@rosiesworkshop.net> wrote:
> > Signed-off-by: Rosie K Languet <rkl@rosiesworkshop.net>> > ---> > This updates the flexible literal promotion algorithm to match current harec > > behavior in promoting signed flexible literals to unsigned integer types.> > language/expressions.tex | 14 +++++++++-----> > 1 file changed, 9 insertions(+), 5 deletions(-)> > diff --git a/language/expressions.tex b/language/expressions.tex> > index 0d47f53..dcbc110 100644> > --- a/language/expressions.tex> > +++ b/language/expressions.tex> > @@ -2809,11 +2809,15 @@ which shall be the result of the promotion.> > > > \specsubitem> > If one operand is a flexible integer and the other is a non-flexible type, the> > -promotion shall succeed only if the non-flexible type is an integer type, and> > -the minimum and maximum value fields of the flexible integer are representable> > -within the non-flexible integer type without any data loss. If the promotion> > -succeeds, the flexible integer shall be lowered to the non-flexible integer> > -type, which shall be the result of the promotion.> > +promotion shall succeed only if the non-flexible type is an integer type and if> > +the maximum value field of the flexible integer is representable within the> > +integer type without any data loss. If the integer type is signed, the promotion> > +shall succeed only if the minimum value field is also so representable. If the> > +integer type is unsigned and the flexible integer is negative, it shall be first> > +promoted to the corresponding (equal-width) signed integer type, and then> > +bit-cast to the unsigned type. If the promotion succeeds, the flexible integer> > +shall be lowered to the non-flexible integer type, which shall be the result of> > +the promotion.> > > > \specsubitem> > If one operand is a flexible rune, the promotion shall succeed if the other type> > -- > > 2.47.1>
This patch is malformed.
> diff --git a/language/expressions.tex b/language/expressions.tex> index 0d47f53..dcbc110 100644> --- a/language/expressions.tex> +++ b/language/expressions.tex> @@ -2809,11 +2809,15 @@ which shall be the result of the promotion.> > \specsubitem> If one operand is a flexible integer and the other is a non-flexible type, the> -promotion shall succeed only if the non-flexible type is an integer type, and> -the minimum and maximum value fields of the flexible integer are representable> -within the non-flexible integer type without any data loss. If the promotion> -succeeds, the flexible integer shall be lowered to the non-flexible integer> -type, which shall be the result of > the promotion.
I suspect a - is missing in front of this line.