Re: tidy binaries

At 06:51 AM 5/26/2005 -0700, Cory Nelson wrote:
>Yup, Win64.  A ptr_type would be the easiest way out.  FYI, VC++
>defines intptr_t and uintptr_t in stddef.h.

Good to know.  I.e. are these ISO C standard?  I'll check out what Solaris 
supports at work today.  Anyone have access to other *nix boxes to verify 
the local equivalents?


>It would be nice to avoid this entirely and do a union { char *s; int
>i; } when storing options, though from trying to make these changes
>myself it quicky got overwhelming as there are many blocks that depend
>on it being a ulong.

My dim recollection is that I tried that to start and backed off because of 
hassles with static initialization in config.c.


>The errors with user-defined structs (user data, TidyInputSource,
>TidyOutputSink) were all quick fixes.

OK, saw that in the diffs.  Surprised the Alpha compiler didn't complain 
about these.  Good catch.

But this raises a general question about 64-bit pointers: in a program that 
would fit into a 32-bit memory model, is it safe to lose the upper 32-bits 
of pointer values?  Probably not in general.  I suppose some CPUs might 
implement a segmented scheme (like the 8086 of old) vs. a flat, linear 
address space.


> > For the record, the types ulong, uint, etc. are pre-defined for many Unix
> > compilers.
>
>That's understandable, as some platforms differ in size.  But pointers
>I still can't understand :)

I don't get why "long" is ever different than a pointer size 
either.  Perhaps MS gets better performance using 32-bit values even on a 
64-bit CPU.  When you really need a large integer, you have to ask for it.

However, there is nothing platform-specific about how the TidyLib configs 
work.  Nor is anything wired to a particular size.  Currently, the only 
assumption is that sizeof(long) == sizeof(char*).  A safer way to express 
this in the source might be sizeof(uintptr_t) == sizeof(char*) and 
sizeof(uintptr_t) >= size(ulong).

Perhaps the old standby void* would be best of all.



> > At 04:21 AM 5/23/2005 -0700, Cory Nelson wrote:
>As an additional note, the standard calling convention for WIN64 is
>__fastcall, so the TIDY_CALL code should probably be changed:
>
>#ifndef TIDY_CALL
>#if defined(_WIN64) // note _WIN32 will also be defined, so we must
>test _WIN64 first.
>#define TIDY_CALL __fastcall
>#elif defined(_WIN32)
>#define TIDY_CALL __stdcall
>#else
>#define TIDY_CALL
>#endif
>#endif

Is __fastcall the compiler default on WIN64?  If so, there is no need to 
set it explicitly.  If not, perhaps this is better handled in the 
build.  Does anyone use TIDY_CALL for .NET or other wrappers on Win64?

Sorry asking so many dumb questions about 64-bit code and Win64 in 
particular.  But I have not had a chance to work with either yet.  I 
appreciate your knowledge on this, Cory.

take it easy,
Charlie




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005