Antonio, Yes...I concur. That is a better solution as it is agnostic to bus width and lets each platform compiler deal with the issue more cleanly. The solution I proposed admittedly would still be a problem on some architectures.
I seem to have a faint recollection that a few non-gnu compilers don't always support "%p" as a formatting code. This is probably a non-issue for OpenOCD, however, since most -- if not all -- people who build the software are probably doing so with gnu gcc and its standard libraries anyway. Gary On 8/21/11 4:43 PM, "Antonio Borneo" <[email protected]> wrote: > On Mon, Aug 22, 2011 at 7:21 AM, Tomek CEDRO <[email protected]> wrote: >> Hello Carlson and thank you for your support! :-) >> >> On Sun, Aug 21, 2011 at 9:09 PM, Carlson Gary >> <[email protected]> wrote: >>> I didn't realize there was a fork for SWD support, so my original attempt >>> was based on the master branch. Nevertheless I cloned the fork that you >>> indicated and immediately ran into a number of compiler issues trying to >>> compile it on a Mac OS X platform. The patch attachment covers most of the >>> changes necessary to address those problems. These should be neutral for >>> other platforms, but you may want to make sure. >>> (..) > > Tomek code prints pointers by casting to int and using format string "0x%08X". > - LOG_INFO("New SWD context initialized at 0x%08X", > (int)jtag_interface->transport->ctx); > > Carlson patch changes the cast to type intptr_t, and seams also using > 64 bits since changes format string to "0x08lX" > + LOG_INFO("New SWD context initialized at 0x%08lX", > (intptr_t)jtag_interface->transport->ctx); > > A more appropriate way to print pointers is through the format string > "%p", that does not require casting and is portable across 32 and 64 > bits. > Above line should be replaced with > + LOG_INFO("New SWD context initialized at %p", > jtag_interface->transport->ctx); > Tested across Linux x86 and Mac OS X x86-64 > > Best Regards, > Antonio Borneo _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
