Re: tidy binaries

At 1:55 PM -0400 5/29/05, Charlie wrote:
>Hi Terry,
>
>At 01:05 AM 5/29/2005 -0700, Terry Teague wrote:
>>At 9:43 AM -0400 5/27/05, Charlie wrote:
>> >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.
>>
>>Don't forget that TidyLib is supported on platforms other than Un*x.
>
>Can you tell us, do your Mac compilers support these types?


Yes. But there are other platforms.


>> >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.
>>
>>
>>Actually there is one dependency on size - perhaps if we are fixing this
>>64-bit stuff, we should fix that as well. The opaque data structures,
>>specifically TidyIterator, rely on the size of enums being 'int', which I
>>believe is the default behavior for ISO C standard compilers. However I
>>found out the hard way that some compilers can implement enums differently
>>(usually as the result of a compiler setting - gcc has a -fshort-enum
>>option), where the enums may be stored as chars, unsigned or signed
>>quantities etc - changing the size of enums does break TidyLib (when I last
>>tried) - see the warning in "platform.h".
>
>Isn't our size assumption actually sizeof(enum) <= sizeof(struct
>_TidyIterator *).
>
>It seems very safe to assume that an enum will be no bigger than a
>pointer.  I don't see how these gcc options would break TidyLib.  Can you
>describe the problems you encountered?


Unfortunately I don't remember (and I can't find any notes) what the
problem was, but it was probably bad (crash), otherwise I wouldn't have
raised the issue. I probably should have fixed the bug in the code, or at
least wrote a bug report. It was just easier to change my compiler settings
<grin>.

But just to see what would happen if I did change the compiler (Metrowerks)
enum size with the current TidyLib code, I did just that (nearest integral
size). A quick test of tidying a document revealed no problem.

But giving the "-xml-config" option to Tidy gave the same kind of problem
we are currently chasing down with 64-bit code :

	Fatal error: impossible value for id='255'.

(for 64-bit id='-1')

Not sure who originally changed use of TidyOptionId to use of "int" in
getNextOption() in "config.c", but Arnaud fixed that in the past day or so
ago. While debugging the 64-bit case, I did try various casts,
dereferences, and assignments, with little success.


I suggest you use a compiler option on your favorite compiler to change the
size of enum, and run Tidy with the "-xml-config" option and see what you
get.


>take it easy,
>Charlie


Regards, Terry




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