[ragel-users] Debugging colm for win32.

[Mel Davis]

Ragel in the git repo is built with an embedded colm processor.? So the first step towards building ragel on Windows is to build colm.? For win64,
fairly extensive changes would be needed since colm assumes pointers =
long data type, but in windows pointers = long long.

However, I
can easily build colm for win32 with msys/mingw just by commenting out a
couple of? unneeded headers.? All the tests pass, except for:?
??? binary1, exit4 thru exit 6 ( they crash with access violations)
??? multiregion2 (it fails parsing the 2nd line, which is blank. I expect it's just a CRLF issue with the script.)

I
can then compile ragel with no changes, but it fails every test. It
always reports a parse error in the ".ri" file at the first "}$" line.

There

is no user guide for colm, so it's difficult for me to debug.?? I know
Adrian Thurston is not building for windows.? but I was hoping that
someone with intimate knowledge of the software could point me to a
place to start.?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.complang.org/pipermail/ragel-users/attachments/20140331/dac56a1c/attachment.html>

[Jan Kundrát]

Post by Mel Davis
Ragel in the git repo is built with an embedded colm
processor.

FYI, this is different version than any Ragel released so far. There's a
ragel-6 (IIRC) branch in the repo which corresponds to the version which is
released.

Last time I tried the rewritten ragel, it choked on many constructs. I
reported that on this ML, but didn't get any feedback, so I presume this is
still an unfinished work.

Cheers,
Jan

[Adrian Thurston]

Indeed, still a work in progress. I am rewriting the code generators in the new style. About halfway done. After that I will probably work on stability.
------Original Message------
From: Jan Kundr?t
Sender: ragel-users-bounces at complang.org
To: ragel-users
ReplyTo: ragel-users
Subject: Re: [ragel-users] Debugging colm for win32.
Sent: Mar 31, 2014 3:23 PM

Post by Mel Davis
Ragel in the git repo is built with an embedded colm
processor.

FYI, this is different version than any Ragel released so far. There's a
ragel-6 (IIRC) branch in the repo which corresponds to the version which is
released.

Last time I tried the rewritten ragel, it choked on many constructs. I
reported that on this ML, but didn't get any feedback, so I presume this is
still an unfinished work.

Cheers,
Jan

[Bob Paddock]

Post by Mel Davis
For win64,
fairly extensive changes would be needed since colm assumes pointers = long
data type, but in windows pointers = long long.

I've not looked at the code in question, so don't know if this helps.

Pointers should not be long nor long long they should be size_t .

See <stddef.h> and <stdint.h>.

When we move to 128 bit parts we'd have to go down this road again,
that is what size_t is meant to prevent. It is the difference between
memory space and arithmetic bit widths.

[William Ahern]

Post by Bob Paddock

Post by Mel Davis
For win64,
fairly extensive changes would be needed since colm assumes pointers = long
data type, but in windows pointers = long long.

I've not looked at the code in question, so don't know if this helps.
Pointers should not be long nor long long they should be size_t .
See <stddef.h> and <stdint.h>.
When we move to 128 bit parts we'd have to go down this road again,
that is what size_t is meant to prevent. It is the difference between
memory space and arithmetic bit widths.

This isn't true in C. In C the only well-defined way to convert a pointer to
an integer and back again is via intptr_t or uintptr_t.

Does C++ really require the same behavior for size_t?

[Bob Paddock]

Post by William Ahern
This isn't true in C. In C the only well-defined way to convert a pointer to
an integer and back again is via intptr_t or uintptr_t.
Does C++ really require the same behavior for size_t?

cstdint.hpp from Boost, which is what I have at hand says:

// intptr_t/uintptr_t are defined separately because they are optional
and not universally available

size_t and relatives should always be available unless using compilers
that are not compliant to standards and don't come with stdint.h .

Alas pointers are mine fields due to the varying widths, such as this
from the C99 Standard:

/*
* You may not even convert a void * to a function
* pointer by explicit casting (6.3.2.3|1).
*
* C's abstract machine does not assume that code and
* data are addressed the same way, so as far as C is
* concerned function pointers and data pointers have
* nothing to do with each other (they could have
* different widths).
*/
Which can lead to the sickening mess of pointer decoration that has no
standard between compilers.

The bottom line is it is always wrong to use (long) long as a pointer
type. What to use in its place depends on the tools being used.

[William Ahern]

Post by Bob Paddock

Post by William Ahern
This isn't true in C. In C the only well-defined way to convert a pointer to
an integer and back again is via intptr_t or uintptr_t.
Does C++ really require the same behavior for size_t?

// intptr_t/uintptr_t are defined separately because they are optional
and not universally available

intptr_t and uintptr_t are optional because the ability to do a round-trip
conversion from a pointer through an integer is not something all
environments support or that the standard requires. The C standard only
provides intptr_t as a common type _if_ the environment supports the
operation.

If <stdint.h> is available, then I'd be surprised if intptr_t wasn't
defined, presuming the operation was supported. <stdint.h> was created by
C99, the same standard that defined intptr_t.

size_t is only required to be wide enough to describe the size of any
_single_ valid object in the system, which basically means wide enough for
the sizeof operator to work. Pointers can be wider than size_t. The most
common example was x86 real mode, but everybody discounts that as no longer
applicable.

If you Google around, you'll find that, for example, the C environment for
the AS/400 (and successors) has 128-bit data and function pointers but
size_t is only 32-bit and doubles 64-bit. Therefore, presuming the AS/400
supported integer/pointer conversions (it might not, because that might
allow circumventing memory capability protections), you would have to use
intptr_t or uintptr_t.