Ticket #883 (new cage)

Opened 5 years ago

Last modified 4 years ago

Use the right PTR2INTVAL() macro, not (INTVAL) for type conversion

Reported by: jimmy Owned by:
Priority: normal Milestone:
Component: core Version: 1.4.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


As discussed on #parrot, see  http://irclog.perlgeek.de/parrot/2009-07-28#i_1349222 for more information.

We should change more place to use PTR2INTVAL() marco, not (INTVAL), see https://trac.parrot.org/parrot/changeset/40306/ for an example.

Change History

Changed 5 years ago by jimmy

This happened when it is a PTR -> INTVAL type conversion

Changed 5 years ago by Util

  • summary changed from Use the right PTR2INTVAL() marco, not (INTVAL) for type conversion to Use the right PTR2INTVAL() macro, not (INTVAL) for type conversion

Changed 5 years ago by NotFound

  • type changed from bug to cage

Changed 4 years ago by jkeenan

  • component changed from none to core

Changed 4 years ago by jkeenan

If we are to pursue the idea suggested by jimmy in this ticket, it would be a good idea to assemble of list of the places where the change should be made. Anyone want to take that on?

Changed 4 years ago by cotto

What's the benefit of making these changes? If there's no measurable benefit (e.g. being able to build on a new compiler) to a change, there's not much point. From the log of #parrot, the benefit appears to be the possibility of additional instrumentation in a debug build. I don't find this especially compelling. If there are no objections, I'd like to reject this ticket.

Changed 4 years ago by bacek


This ticket shouldn't be rejected. ptr2intval must be used instead for pointer-to-intval conversion due possible difference between sizeof(void*) and sizeof(int) on some platforms.

-- Bacek

Changed 4 years ago by cotto

Thanks, bacek. This is indeed something we need to fix. ack -a '\(\s*INTVAL\s*\)'|wc -l currently returns 241 after make realclean and isn't guaranteed to be exhaustive in catching misuses. This raises two questions. The first is how we know when to close this ticket. There are legitimate uses for INTVAL casts and we want to make sure that those don't prevent this ticket from being closed. A manual review is probably the best option. The second issue is making sure that this problem doesn't appear again. Unless someone wants to write a codingstd test that parses C well enough to detect this, vigilance is the best way to keep it out.

Changed 4 years ago by cotto

#1046 (Configure.pl allows sizeof(INTVAL) != sizeof(void *), but parrot requires them to be equal.) is relevant

Note: See TracTickets for help on using tickets.