Skip to content
Snippets Groups Projects

libvlc: use size_t instead of optional uintptr_t in libvlc

Closed Steve Lhomme requested to merge robUx4/vlc:libvlc-no-uintptr_t into master
1 unresolved thread

uintptr_t is an optional type in C11 and C++11. For a public API like libvlc it's better to rely on the types found on all C and C++ compilers.

size_t and uintptr_t should be the same on all platforms we support. Maybe we don't need the static_assert once the CI's pass. It would be a silent type change.

Host app will either generate a new error or warning and need to be updated or not and will continue to work as before because they are the same type underneath.

libvlcpp will need to be updated accordingly.

Edited by Steve Lhomme

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
416 416 * \version LibVLC 2.1.0 or later
417 417 */
418 418 LIBVLC_API void libvlc_log_get_object(const libvlc_log_t *ctx,
419 const char **name, const char **header, uintptr_t *id);
419 const char **name, const char **header, size_t *id);
  • size_t is not large enough. intptr_t can be larger, e.g. on Morello and other CHERI ABIs, they're 64- and 128-bits.

    Besides there's no sense not to define that type. LibVLC also relies on intN_t which is also nominally optional. Nobody ever had a problem with that.

  • Author Developer

    Indeed they are. I also tried to use a void**. Because that's just a pointer value we can display, not do anything with it (no derefence). But it leads to other issues, and it will break compatibility with existing code (if such a code exists somewhere).

  • Please register or sign in to reply
  • closed

  • Please register or sign in to reply
    Loading