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

ctypes defines global symbols #47352

loewis mannequin opened this issue Jun 13, 2008 · 11 comments

ctypes defines global symbols #47352

loewis mannequin opened this issue Jun 13, 2008 · 11 comments


Copy link

loewis mannequin commented Jun 13, 2008

BPO 3102
Nosy @loewis, @theller, @doko42
  • rename.patch: Rename a lot of ctypes symbols
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = ''
    closed_at = <Date 2009-04-24.20:51:52.266>
    created_at = <Date 2008-06-13.07:54:53.170>
    labels = []
    title = 'ctypes defines global symbols'
    updated_at = <Date 2009-04-24.20:51:52.264>
    user = '' fields:

    activity = <Date 2009-04-24.20:51:52.264>
    actor = 'theller'
    assignee = 'theller'
    closed = True
    closed_date = <Date 2009-04-24.20:51:52.266>
    closer = 'theller'
    components = []
    creation = <Date 2008-06-13.07:54:53.170>
    creator = 'loewis'
    dependencies = []
    files = ['13713']
    hgrepos = []
    issue_num = 3102
    keywords = ['patch']
    message_count = 11.0
    messages = ['68135', '73383', '73404', '84332', '85742', '86078', '86099', '86109', '86430', '86431', '86433']
    nosy_count = 3.0
    nosy_names = ['loewis', 'theller', 'doko']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = None
    url = ''
    versions = ['Python 3.1', 'Python 2.7']

    Copy link
    Mannequin Author

    loewis mannequin commented Jun 13, 2008

    ctypes defines a number of global symbols which aren't
    namespace-prefixed, such as AllocFunctionCallback, FreeClosure, GetType,
    IsSimpleSubType, MallocClosure, _AddTraceback, _CallProc,
    alloc_format_string, conversion_mode_encoding, conversion_mode_errors,
    get_error_object, getentry, module_methods (there are more, but the
    other ones can be understood as being unambiguously prefixed, such as
    with CData, CField, StgDict).

    It would be good if these symbols either are changed to static, or get a
    proper Py/_Py prefix.

    @loewis loewis mannequin assigned theller Jun 13, 2008
    Copy link

    theller commented Sep 18, 2008

    Is it too late to fix this for Python 2.6 and Python 3.0?

    Copy link
    Mannequin Author

    loewis mannequin commented Sep 18, 2008

    Formally, I can't answer that question; you need to ask the RM.

    Informally, I think only serious bugs can be fixed now; this bug is not

    Copy link

    doko42 commented Mar 28, 2009

    These are the symbols on the trunk (20090328). There are *very* general
    names as well. How should this be resolved? Introduce macros for the old
    names, or just rename these?

    module_methods probably could be static.


    Note there's a patch to get rid of FreeClosure:

    Copy link

    theller commented Apr 7, 2009

    I think simple renaming would be fine.

    I do not see how module_methods could be made static; however, the
    init_callbacks_in_module function should probably be removed completely.

    Some other symbols could be made static because they are only used in a
    single source file, Array_Type and CData_Type for example (there may be

    For MallocClosure/FreeClosure and the fedoraproject patch: Where does
    ffi_closure_alloc and ffi_closure_free come from?

    Copy link

    theller commented Apr 17, 2009

    Here is a quite large patch (300 lines) against svn trunk that renames a
    lot of symbols.
    The list of symbols, listed by 'nm -g --defined-only' is as

    theller@tubu32:/devel/trunk$ find . -name | xargs nm -g
    00011d07 T My_PyUnicode_AsWideChar
    00011c6e T My_PyUnicode_FromWideChar
    000136e2 T PyCArgObject_new
    000236e0 D PyCArg_Type
    000225a0 D PyCArrayType_Type
    0000f86a T PyCArrayType_from_ctype
    00022e40 D PyCArray_Type
    0000b0b0 T PyCData_AtAddress
    0000ae6f T PyCData_FromBaseObj
    00022980 D PyCData_Type
    0000b274 T PyCData_get
    0000b82d T PyCData_set
    000181bf T PyCField_FromDesc
    00023ae0 D PyCField_Type
    000227e0 D PyCFuncPtrType_Type
    00022b60 D PyCFuncPtr_Type
    00022440 D PyCPointerType_Type
    00023220 D PyCPointer_Type
    00022700 D PyCSimpleType_Type
    00023920 D PyCStgDict_Type
    0001627a T PyCStgDict_clone
    00022200 D PyCStructType_Type
    00017223 T PyCStructUnionType_update_stgdict
    00023300 D PyCThunk_Type
    00004fe4 T PyDict_GetItemProxy
    00004dd1 T PyDict_SetItemProxy
    00023e18 B PyExc_ArgError
    0001660e T PyObject_stgdict
    0001658c T PyType_stgdict
    00023de8 A __bss_start
    0001221b T _ctypes_add_traceback
    00012f75 T _ctypes_alloc_callback
    0001d737 T _ctypes_alloc_closure
    0000506e T _ctypes_alloc_format_string
    0001469d T _ctypes_callproc
    00023dec B _ctypes_conversion_encoding
    00023df0 B _ctypes_conversion_errors
    000143f5 T _ctypes_extend_error
    0001d70a T _ctypes_free_closure
    00013318 T _ctypes_get_errobj
    00013f41 T _ctypes_get_ffi_type
    0001d5be T _ctypes_get_fielddesc
    000237c0 D _ctypes_module_methods
    00023e14 B _ctypes_ptrtype_cache
    0000b204 T _ctypes_simple_instance
    00023de8 A _edata
    00023e1c A _end
    0001e264 T _fini
    00003f48 T _init
    0001dbda T ffi_call
    0001e080 T ffi_call_SYSV
    0001d9fc T ffi_prep_args
    0001d883 T ffi_prep_cif
    0001db62 T ffi_prep_cif_machdep
    0001d9ba T ffi_prep_closure
    0001de09 T ffi_prep_closure_loc
    0001dea0 T ffi_prep_raw_closure_loc
    0001df8b T ffi_raw_call
    00023a64 D ffi_type_double
    00023a58 D ffi_type_float
    00023a70 D ffi_type_longdouble
    00023a7c D ffi_type_pointer
    00023a1c D ffi_type_sint16
    00023a34 D ffi_type_sint32
    00023a4c D ffi_type_sint64
    00023a04 D ffi_type_sint8
    00023a10 D ffi_type_uint16
    00023a28 D ffi_type_uint32
    00023a40 D ffi_type_uint64
    000239f8 D ffi_type_uint8
    000239ec D ffi_type_void
    000115ec T init_ctypes

    doko, loewis, what do you think?

    Copy link
    Mannequin Author

    loewis mannequin commented Apr 17, 2009

    Looks fine to me, except that I wouldn't call things "My*" (but I do
    understand that this unrelated to this issue).

    Copy link

    theller commented Apr 18, 2009

    Correction: The patch has 3000 lines, not 300.

    And I think that the 'My_Unicode_...' functions can be removed because
    they are not used anywhere. I have to check this.

    Copy link

    theller commented Apr 24, 2009

    Fixed in trunk (svn rev 71853).

    I'll leave this open until it is ported to py3k.

    Copy link

    theller commented Apr 24, 2009

    BTW: The 'My_Unicode...' symbols are gone, too.

    Copy link

    theller commented Apr 24, 2009

    svn rev 71845, in py3k branch.

    @theller theller closed this as completed Apr 24, 2009
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    None yet
    None yet

    No branches or pull requests

    2 participants