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

[BUG] Odd warning in generated .c file related to fused type usage #5794

Closed
skunkyevil opened this issue Nov 4, 2023 · 4 comments
Closed

Comments

@skunkyevil
Copy link

skunkyevil commented Nov 4, 2023

Describe the bug

There's an odd warning present when I check for fused type in if clause.
Warning C4244 '=': conversion from 'long' to 'char', possible loss of data

I found mention of the same bug in Internet dated 2015:
https://www.mail-archive.com/cython-devel@python.org/msg04553.html

I minimized the example code

Code to reproduce the behaviour:

ctypedef fused floating:
    float
    double

cpdef add_one(floating [:] array):
    if floating is float:
        pass
        

Copilled with:

from setuptools import setup
from Cython.Build import cythonize

setup(
    name='Hello world app',
    ext_modules=cythonize("bug.pyx"),
)

Expected behaviour

There should be no warning

OS

Windows 10

Python version

3.9

Cython version

3.0.5

Additional context

No response

@scoder
Copy link
Contributor

scoder commented Nov 4, 2023

What warning message do you get?

@skunkyevil
Copy link
Author

Sorry, it was Warning C4244 '=': conversion from 'long' to 'char', possible loss of data. Updated above

@da-woods
Copy link
Contributor

da-woods commented Nov 4, 2023

Probably from

kind = ord(dtype.kind)

(where kind is a char and ord returns a long). PR welcome to fix - I think this could hide a real bug in principle. (At least if Numpy starts using unicode kinds - which would be odd but I guess they could)

@scoder scoder closed this as completed in e584c46 Nov 4, 2023
@scoder scoder added this to the 3.0.6 milestone Nov 4, 2023
@scoder
Copy link
Contributor

scoder commented Nov 4, 2023

Ah, thanks. So this is from generated code on our side. I replaced the char type with Py_UCS4 in e584c46. It comes from a Unicode string, there's no reason why we should cut this down to a char.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants