Fix locale-sensitive decimal parsing in compiled bash/powershell scripts - #6
Open
StacheSebastian wants to merge 1 commit into
Open
StacheSebastian wants to merge 1 commit into
StacheSebastian wants to merge 1 commit into
Conversation
Contributor
|
@StacheSebastian is attempting to deploy a commit to the tronschell's projects Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Both compiler backends parse numeric fields from the statusline JSON (cost,
percentages, timestamps) using APIs that are sensitive to the host's locale.
On any system where
,rather than.is the decimal separator (themajority of non-English locales — German, French, Spanish, Polish, Russian,
Dutch, Nordic languages, Portuguese, Turkish, etc.), this silently corrupts
the rendered statusline instead of erroring:
"total_cost_usd": 6.125108349213767renders as$6125108000000000,00on PowerShell, or fails withprintf: invalid numberand truncates to$6,00on bash.2.34renders as a fullyfilled progress bar (parsed as
234, then clamped to 100).Root cause
__costFmt/__bar/__relTime):[double]::TryParse($v, [ref]$n)— the 2-arg overload — defaults to
NumberStyles.Float | NumberStyles.AllowThousandswith
CultureInfo.CurrentCulture. Under a comma-decimal culture,.isthe culture's group separator, so
AllowThousandssilently strips every.instead of treating it as a decimal point, concatenating the digitsinto a huge integer.
(The
[double](...)cast used for thegt/ltconditional emitters isnot affected by this — verified separately — so that code path is
untouched.)
__cost_fmt, and thegt/ltawkconditionals):printf '$%.*f'andawk's string-to-number coercion can honorLC_NUMERIC/LC_ALL, so a.-decimal JSON value fails to parse correctly under acomma-decimal locale.
Repro
Fix
Force invariant/C numeric parsing at every point a JSON-sourced decimal
string is converted to a number, regardless of the host's locale:
[double]::TryParse($v, [NumberStyles]::Float, [CultureInfo]::InvariantCulture, [ref]$n),
and routed __costFmt, __bar, and __relTime through it.
conditional checks with LC_ALL=C.