Re: tidy binaries

On 5/26/05, Charlie <[email protected]> wrote:
> Hi Cory,
> 
> Sorry late to thread.  Can I ask a question? For which 64-bit
> platform/compiler is an "unsigned long" not 64-bits?  I changed all the
> config values (which is an integer/string/enum union) to use ulong from
> uint a while back to fix the 64-bit builds on Alpha Linux.  And that fixed
> the warnings on the pointer-to-int casts.

VC++.  You must use "long long" or __int64 to get a 64-bit int,
regardless of your target platform.  I think "long long" only exists
as of VC++.NET 2003, while __int64 was in the original VC++.NET

> I'm not arguing here, just asking what the variations are.  Is this for
> Win64?  There have been some suggestions to use special types to handle
> this issue - "ptr_type" IIRC.  Should we bite the bullet and use that?

Yup, Win64.  A ptr_type would be the easiest way out.  FYI, VC++
defines intptr_t and uintptr_t in stddef.h.

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.

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

> For the record, the types ulong, uint, etc. are pre-defined for many Unix
> compilers.  Having grown accustomed to using them, I like to define them on
> Windows or *nix compilers that do not define them.  I probably introduced
> those when I did the initial TidyLib refactoring job.  It's Pure Syntax
> Sugar! (tm)

That's understandable, as some platforms differ in size.  But pointers
I still can't understand :)

> take it easy,
> Charlie
> 
> At 04:21 AM 5/23/2005 -0700, Cory Nelson wrote:
> >On 5/23/05, Terry Teague <[email protected]> wrote:
> > > At 4:59 AM +0200 5/23/05, Bjoern Hoehrmann wrote:
> > > >* Cory Nelson wrote:
> > > >>Hello all, I have updated the tidy binaries page with the latest
> > > >>sources.  Sorry it took so long, I've been busy as of late.
> > >
> > >
> > > I know that feeling.
> > >
> > >
> > > >>minor patchwork on tidy.c line 587- warning about casting on const.
> > > >>this fixes it:
> > > >>const TidyOption* e1 = (const TidyOption*)e1_;
> > > >>const TidyOption* e2 = (const TidyOption*)e2_;
> > > >
> > > >Thanks, can anyone apply this patch?
> > >
> > >
> > > Done.
> > >
> > >
> > > >>I wanted to get a 64-bit build out there, but noticed there is casting
> > > >>between pointers and ulong (which is 32-bit) all over the place.  Is
> > > >>there a reason these weren't just kept as pointers?
> > > >
> > > >http://tidy.sf.net/bug/685603 and some discussion on this list have
> > > >details. If I remember correctly, the current code should reflect
> > > >changes for 64Bit support on some non-Win32 platforms. As I've pointed
> > > >out in the bug report, this does not play well with Win32.
> > >
> > >
> > > In response to <http://tidy.sf.net/bug/1192885>, I have started looking at
> > > 64-bit support again. I have got a bunch of warnings when building 64-bit
> > > on my platform, that I need to sort out - I will add info to the 64-bit bug
> > > report and/or fix the obvious problems.
> > >
> >
> >IMHO, the idea of casting pointers to typedefed integers (let alone a
> >fixed 32-bit 'ulong') is ridiculous in the first place.  I can
> >understand typedefing int32 and int64 etc but what reasoning was there
> >to do this with very platform specific pointers?  I'd be happy to
> >attempt a patch, but i'm still not 100% familiar with the Tidy code
> >and don't want to break some obscure code that relies on it being an
> >int.
> >
> >Some fairly complex C++ I have runs in about 1/6th the time on 64-bit,
> >so I'm excited to see if Tidy gets similar benefits.
> >
> > >
> > > FYI, there are some changes being made on SourceForge that might affect the
> > > automated builds of Tidy. I also need to update the auto-updating of the
> > > docs now that docs in XML format are produced by Tidy itself. So there
> > > might be some breakage for a while...
> > >
> > >
> > > Regards, Terry
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > Want to be the first software developer in space?
> > > Enter now for the Oracle Space Sweepstakes!
> > > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> > > _______________________________________________
> > > Tidy-develop mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/tidy-develop
> > >
> >
> >
> >--
> >Cory Nelson
> >http://www.int64.org
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by Oracle Space Sweepstakes
> >Want to be the first software developer in space?
> >Enter now for the Oracle Space Sweepstakes!
> >_______________________________________________
> >Tidy-develop mailing list
> >[email protected]
> >https://lists.sourceforge.net/lists/listinfo/tidy-develop
> 
>

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


-- 
Cory Nelson
http://www.int64.org


-------------------------------------------------------
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