Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[makefilename] and large-float to integer conversion #812

Open
Lucarda opened this issue Dec 6, 2019 · 6 comments
Open

[makefilename] and large-float to integer conversion #812

Lucarda opened this issue Dec 6, 2019 · 6 comments

Comments

@Lucarda
Copy link
Contributor

@Lucarda Lucarda commented Dec 6, 2019

There is an issue with [makefilename], integers are not transformed and or displayed correctly.

In this patch [makefilename %f] prints the correct number but not [makefilename %d] :

makefilename

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 6, 2019

good catch.

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 6, 2019

2.22212e+009 is beyond the positive range of 32 bit integers (2^31 - 1). We've fixed the [int] object to use 64 bit integer casts internally, but the %d format specifier is 32-bit.

The problem is that [makefilename] really maps to the C printf format specifiers and %d is only for 32-bit integers. Before C99 there wasn't even a standardized specifier for 64-bit ints; since then it's %lld, %llu, etc.

We could introduce the ll prefixes to [makefilename], but Pd is still a pure C89 codebase (to support old MSVC versions). One solution could be to internally replace ll with the "correct" platform dependent format specifier.

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 8, 2019

i think that [makefilename %d] shouldn't print INT_MIN for large (positive) values. it rather should print INT_MAX.

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 8, 2019

Actually, I'm a bit surprised that @Lucarda and I always get INT_MIN on overflow... OTOH, since signed integer overflow is undefined behavior, the compiler might just as well decide to format the harddrive or destroy the universe.

You're right that we should do bound checking and clamp the input. Maybe also print an error on overflow? For the sake of correctness, we should also add UINT to t_printtype, to honor the bigger range.

@umlaeute umlaeute changed the title double-precision: [makefilename] and integers. [makefilename] and large-float to integer conversion Dec 8, 2019
@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 8, 2019

btw, this is not at all related to double-precision.
i get the same behaviour for a normal (single-precision) Pd-0.50-2 build.

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 9, 2019

python handles this totally transparently to the user (no saturation), which is kind of neat:

>>> print("%f" % 1e123)
999999999999999977709969731404129670057984297594921577392083322662491290889839886077866558841507631684757522070951350501376.000000
>>> print("%d" % 1e123)
999999999999999977709969731404129670057984297594921577392083322662491290889839886077866558841507631684757522070951350501376
>>> 

for this, they build the integer-representation manually:

https://github.com/python/cpython/blob/a2ff283d519be11f50220885ddc4d029eb8cb0a0/Objects/longobject.c#L432-L470

I don't know whether we want to go this route though...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.