Re: Euphoria 4.1 problem - as relates to tinewg

new topic     » goto parent     » topic index » view thread      » older message » newer message
jimcbrown said...
mattlewis said...

I would not have removed these from std/dll.e. Your comment in the commit implies that users could just go to the demo to get them.

Agreed. They could even just include it directly. Though maybe it makes sense to have a std/include/w32api/w32dllconst.ew instead ?

That would be better than keeping them in a demo. Having the extra constants around seemed easier to me than making them only be available on certain platforms to accommodate lazy / sloppy devs, but either a separate file or an ifdef would be OK, so long as they're in the stdlib.

jimcbrown said...
mattlewis said...

But these are extremely common Windows types. Having them there means that we've already figured out what Windows wants when it wants a HANDLE or a LONG_PTR. This just puts a larger burden on the euphoria programmer to have to figure out the Windows type system and how that translates into euphoria.

I think the consensus was that we had done it wrong in the first place.

WHARGARBLE! Yeah, if I got the types wrong, that should definitely be fixed. It's kind of hard to keep it all straight across all the platforms. And signed / unsigned often doesn't really matter (for instance, on 64-bit all pointers will be the same signed or unsigned) but it's marginally better to be pedantically correct than "it works" correct. (Semi-on topic, I was building the head of the trunk from scratch and getting failing errors on call_c tests - 64-bit Linux, so something in there has regressed...went back to the memstruct branch for now - haven't had a chance to investigate further.)

ghaberek said...

I do think we'll need Matt to chime in here to confirm this is a simple mistake or explain any further reasoning he had for the change to signed values. I'm not even sure what C_LONG_PTR is really for or why you would want to interpret pointers as signed values.

I think that one is actually a signed integer that's the same size as a pointer, so signed is correct. It's a consequence of 64-bit Windows using a 32-bit long integer. Yes, the name is dumb, but it is what it is, and is another one of those backwards compatibility things that Microsoft introduced.

Matt

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu