Sat Jun 09 10:38:01 2012: Request 77525 was acted upon.
Transaction: Correspondence added by bulk88.
Queue: Win32-API
Subject: new release - version 0.69
Broken in: (no value)
Severity: Wishlist
Owner: COSIMO
Requestors: bul...@hotmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77525 >
On Sat Jun 09 07:20:25 2012, COSIMO wrote:
> I have read most of your patch.
>
> It's somewhat difficult to digest all the changes together.
> I think it would have been easier to get a series of commits, maybe in a
> forked git repository (hint :)
>
> I'm impressed by the amount of work you did. I'd like someone else to
> have a look at this patch, but my feedback is:
>
> * Not sure the Win32::API/Win32::API::More namespace split is the best
> solution. I'd suggest reaching out to Win32::API users to estimate how
> much work it would be to change "Ss" for short ints.
I did. http://perlmonks.org/?node_id=970481
http://perlmonks.org/?node_id=970206 ::API is more than 10 years old,
::More is required. If I get rid of ::More, all existing scripts that
use Win32::API with a pointer to a number will break, and all existing
scripts that used an unsigned prototype or unsigned type letter will
start to get unsigned numbers rather than signed, so == comparisons will
all fail, also all existing scripts that use S for structure will have
to be changed. If you are willing take responsibility, I can move
::API::More's features/behavior to ::API and remove ::API::More.
> * Please avoid the WIN32_API_SORRY_I_WAS_AN_IDIOT variable, and rename it
> to something that explains the purpose of it.
I couldn't think of a aggressive enough name that explains that never to
use this option so someone suggested that. There are 3 things that can
be done about that flag.
1. Leave the flag documented, and can you think of a better name that
truly discourages anyone from using the option? I predict this option
will be very popular for alot of people with Win32::API code. Even
0.68's own test suite had 1 or 2 buffer overflows in its code that were
caught.
2. Totally de-document the flag so someone would have to look through
the source to find that it exists, and if they complain >0.68 broke all
their scripts, they can be told about the flag.
3. This is a security fix. Remove the flag outright. There is no excuse
for corrupted memory. Go use 0.68 from CPAN if you want buffer overflows
that badly.
