nick rothwell | project cassiel

object_post((t_object *)x, "a new %s object was instantiated: 0x%X", s->s_name, x);

 isn't qualified, isn't this wrong for 64-bit pointers?

I get a slightly different (and possibly correct) answer for:

object_post((t_object *)x, "a new %s object was instantiated: 0x%llX", s->s_name, x);

although that's not very portable. The C99 standard is something like

object_post((t_object *)x, "a new %s object was instantiated: 0x" PRIxPTR, s->s_name, x);

Is there a sanctified way to do this? (I'll try the standard 

I'm looking at simplemax.c. The new function does this:

Since the %X isn't qualified, isn't this wrong for 64-bit pointers?

but object_post doesn't seem to work with that (I get 1x printed for the pointer value).

Is there a sanctified way to do this? (I'll try the standard sprintf to see what that produces.)

token-newbie-64-bit-question

On my platform [ MacOS 10.8.3 running Max 6.1.1 (64-bit) ] this seems to work and should also be portable.

object_post((t_object *)x, "a new %s object was instantiated: %p", s->s_name, x);

The only problem I see is that there's no really good way to determine the maximum length of the string produced by "%p". However, for most uses it should be fine.

For what it's worth, here's my test code:

object_post((t_object *)x, "object via %%X:      %X", x);
object_post((t_object *)x, "object via %%llX:    %llX", x);
object_post((t_object *)x, "object via %%p:      %p", x);
object_post((t_object *)x, "object via PRIxPTR: %" PRIxPTR, x);

simplemax: object via %X:      BE944A8
simplemax: object via %llX:    C00670BE944A8
simplemax: object via %p:      0xbe944a8
simplemax: object via PRIxPTR: be944a8

simplemax: object via %X:      C4A2578
simplemax: object via %llX:    10C4A2578
simplemax: object via %p:      0x10c4a2578
simplemax: object via PRIxPTR: 10c4a2578

 complaint earlier: I woz doing it wrong.)

, which must translate to 8-bytes in a 64-bit env.

 appears to deliver the low-order long, and (after more experimentation) doesn't appear to corrupt the stack. (I don't immediately understand why not, unless it's some register allocation business. I've not done machine code for decades.)

 corrupts the stack (so it's still 64 bits); 

 of the example code appears benign, but the value is wrong. Tim: could you consider this a manual GitHub pull request to make this 

Ah, %p. I've been using Java for too long...

(Ignore the PRIxPTR complaint earlier: I woz doing it wrong.)

PRIxPTR appears to be "lx", which must translate to 8-bytes in a 64-bit env.

In 64 env, %X appears to deliver the low-order long, and (after more experimentation) doesn't appear to corrupt the stack. (I don't immediately understand why not, unless it's some register allocation business. I've not done machine code for decades.)

In 32 env, %llX corrupts the stack (so it's still 64 bits); %lX works fine (so must mean 32 bits here).

So for 64 bits the %X of the example code appears benign, but the value is wrong. Tim: could you consider this a manual GitHub pull request to make this %p or "%" PRIxPTR?


#ifdef MAC_VERSION
#ifndef powerc
#pragma d0_pointers on
#endif
...

 is a nice one to have, and it would be nice if the build were still clean.

While I'm here: turning on -Wall in Xcode gives me Unknown Pragma in

(in ext_prefix.h.) It seems that -Wall is a nice one to have, and it would be nice if the build were still clean.


Token newbie 64-bit question