Replying to various postings at once: Mark Hammond wrote:
Well, I am afraid it is slightly more than "no problem" for me if it means I need to read the doc for and potentially touch *every single* function in the Win32 extensions that accepts an integer as an input arg.
Exactly the same here. I have 2206 automatically generated Mac API functions, and each of these would have to be inspected. Martin v. Löwis wrote:
To silence the warning, you should really add "L" suffixes to all those literals - or we could provide a future statement, where you indicate that you want those literals to become positive longs *now*; you'ld need to add this statement once per module.
The future statement would solve most of the headaches (combined with the 32 bit value parser that accepts both int and long). Martin again:
If we think that the case "large numbers are bitmaps" is more common than the case "large numbers are large numbers", we should drop the range check for the existing converters, and add new converters in case somebody wants large numbers instead of bitmaps, which then do the range checks.
This would be ideal, of course. But note that for me changing the format char is a minor issue, as long as the behavior of the new format char is as expected (any 32 bit value is okay, and iff there is a way 32 bit constants can become longs in the parser then those longs should be passed as 32 bit ints too). Those 2206 routines mentioned above are automatically generated. There are a couple of tens of manually generated wrappers, but as I've written those myself, mainly, there's a chance I will know what to do:-) But of course I don't know how this would be for Mark... -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -