Skip Menu |

This queue is for tickets about the String-Similarity CPAN distribution.

Report information
The Basics
Id: 13403
Status: resolved
Priority: 0/
Queue: String-Similarity
People
Owner: Nobody in particular
Requestors: bjoern [...] hoehrmann.de
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Fri Jun 24 19:51:47 2005 Guest - Ticket created
Subject: CHAR typedef conflicts with WinNT.h
The `typedef UV CHAR;` in fstrcmp.h conflicts with the CHAR type in WinNT.h on Win32 systems. The type should be named differently so the module can be compiled using MSVC++.
  Mon Dec 05 19:02:27 2005 MLEHMANN [...] cpan.org - Correspondence added
[guest - Fri Jun 24 19:51:47 2005]: Show quoted text
> The `typedef UV CHAR;` in fstrcmp.h conflicts with the CHAR type in > WinNT.h on Win32 systems. The type should be named differently so the > module can be compiled using MSVC++.
The module uses standard C, which allows the use of the identifer CHAR. It's much more worthwhile to just use a C compiler (or fix MSVC++) instead of porting each and every bit of code to some microsoft-specific dialect.
  Mon Dec 05 19:02:28 2005 MLEHMANN [...] cpan.org - Status changed from 'new' to 'resolved'
  Mon Dec 05 19:47:46 2005 The RT System itself - Status changed from 'resolved' to 'open'
  Mon Dec 05 19:47:46 2005 MLEHMANN [...] cpan.org - Correspondence added
[derhoermi@gmx.net - Mon Dec 5 19:32:24 2005]: Show quoted text
> > You are free to use it, but not twice with incompatible types as you > currently do, your
This is utter bullshit, please first have a look at the code before claiming such nonsense. Show quoted text
> #include "EXTERN.h" > #include "perl.h" > #include "XSUB.h" > > #include "fstrcmp.h" > #include "fstrcmp.c" > > resolves to > > ... > typedef char CHAR; > ... > typedef UV CHAR; > ... > > which is not allowed.
It doesn't do so on (ISO-C-) compliant systems, and it doesn't do so on mine. If it does on yours, then this is a compiler/os-environment bug, not a bug in the code (which only defines the idnetifier ONCE, not, as you claim, twice! The other deifnition is a bug in your system). Again, it would be more useful to fix this bug in the compiler, not in all other packages. Microsoft systems, in general, are too broken to be be worth the portability nightmare ine would have to enter for just that single outdated platform.
  Tue Dec 06 08:28:05 2005 MLEHMANN [...] cpan.org - Correspondence added
[derhoermi@gmx.net - Mon Dec 5 20:08:55 2005]: Show quoted text
> Well, I see you won't make the change, but I would appreciate if you > could realize that this problem does not arise due to any form of non- > compliance; the Perl developers chose to include WinNT.h in the > headers
This is neccessary as a workaround. Microsoft claims, among other things, full unix compatibility, which isn't delivered, however. On a unix (sus) system, including winnt.h is not required. Show quoted text
> you include, Microsoft chose to have a CHAR typedef and you chose to
microsoft chose to be incompatible, and try to make the lfie of developers harder to bind them to their monopoly. Show quoted text
> have a different typedef for the CHAR symbol. Now you can blame the > Perl > developers or Microsoft for not foreseeing that you might wish to use > the CHAR symbol this way, but that won't help Win32 users who wish to > use your module.
You need to realize that this is a problem caused by mcirosoft, not by individual developers of perl modules (or perl).
  Wed Dec 07 16:05:09 2005 MLEHMANN [...] cpan.org - Status changed from 'open' to 'resolved'