New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warning "/* within comment" in Win32 config.h-related files #10059
Comments
From @kmxCreated by @kmxHi, I would like to propose a cosmetic fix to some "config.h-related" files ### What is the problem? The issue occurs when some module with XS part tries to '#include C:/strawberry/perl/lib/CORE/config.h:39:20: warning: "/*" within comment ### Why does it happen? The reason is that in config.h there are blocks like this: /* HAS_FORK: And as you can see the line with "#define HAS_FORK" obviously has some ### How to fix it? The proper way of handling this should be using: ### Where does it occurs? ./win32/config_H.bc Could you please consider cleaning up the header files mentioned above? Considering the number of incorrect lines (approx. 3000 in total in all Thanks. -- Perl Info
|
@kmx - Status changed from 'new' to 'open' |
From zefram@fysh.orgkmx wrote:
That would miss the point of having the "/**/" at the end of the line. /* #define HAS_FORK */ and the active version might be either of #define HAS_FORK
The lines are not incorrect. The definition of the C language is -zefram |
From @TuxOn Tue, 05 Jan 2010 04:58:52 -0800, kmx (via RT)
The code that is having these `problems' is generated code. Cleaning it The generation code is not as simple as it it might look, so I don't Maybe your C-compiler has an option to suppress these specific warnings.
-- |
From @kmxHello,
Well, I am not sure that this is true for ./win32/config_H.* files which
Our (= strawbery perl) compiler is gcc that can surely suppress them but Just to illustrate what 'annoying' means in this case - if you install I understand that it has no priority as it is only cosmetics and affects -- |
From @nwc10On Wed, Jan 06, 2010 at 10:09:49AM +0100, kmx wrote:
oops. Merijn seems to have missed that you're referring to the Win32 files,
That Win32 is not core is a myth when it comes to the core perl. It may be Please stop perpetuating untruths. I *think* that the files in question are generated by win32/config_h.PL As you clearly care about this issue, and are in a position to verify that The repository is as http://perl5.git.perl.org/perl.git Nicholas Clark |
From @kmxHi Nicholas,
Please find enclosed patch for config_h.PL that does: I have tried to recreate some win32/config_H.* To sum up, I do not know who/when/how initiates regeneration of the files: It seems that it is not only by simply running config_h.PL - there seems -- |
From @kmxwin32_config_h.PL.patchdiff --git a/win32/config_h.PL b/win32/config_h.PL
index 531ddce..89b8553 100644
--- a/win32/config_h.PL
+++ b/win32/config_h.PL
@@ -8,7 +8,8 @@ BEGIN
}
use File::Compare qw(compare);
use File::Copy qw(copy);
-my $name = $0;
+use File::Basename qw(fileparse);
+my ($name, $dir) = fileparse($0);
$name =~ s#^(.*)\.PL$#../$1.SH#;
my %opt;
while (@ARGV && $ARGV[0] =~ /^([\w_]+)=(.*)$/)
@@ -62,6 +63,7 @@ while (<SH>)
munge();
s/\\\$/\$/g;
s#/[ *\*]*\*/#/**/#;
+ s#(.)/\*\*/#$1/ **/# if(/^\/\*/); #avoid "/*" inside comments
if (/^\s*#define\s+(PRIVLIB|SITELIB|VENDORLIB)_EXP/)
{
$_ = "#define ". $1 . "_EXP (win32_get_". lc($1) . "(PERL_VERSION_STRING, NULL))\t/**/\n";
@@ -69,7 +71,7 @@ while (<SH>)
# incpush() handles archlibs, so disable them
elsif (/^\s*#define\s+(ARCHLIB|SITEARCH|VENDORARCH)_EXP/)
{
- $_ = "/*#define ". $1 . "_EXP \"\"\t/**/\n";
+ $_ = "/*#define ". $1 . "_EXP \"\"\t/ **/\n";
}
print H;
}
|
From @steve-m-haykmx wrote on 2010-01-06:
But this patch "fixes" the problem by changing /**/ to / **/, which it has already been commented by others is undesirable as it breaks the convenience of the whole /* ... /**/ idea.
I've regenerated these files several times in the past. There are some comments in the Win32 makefiles above the regen_config_h target about how to do it, but you're right that it does require some manual editing too and is quite fiddly to do. |
From @sisyphus----- Original Message -----
I think that's correct (except I think it was between 5.11.1/5.11.2). I think we could probably just amend those 2 files - I don't expect that Cheers, |
From @doughera88On Thu, 7 Jan 2010, Steve Hay wrote:
It's a question of balancing the editing convenience of that little trick -- |
From @craigberryOn Thu, Jan 7, 2010 at 7:50 AM, Andy Dougherty <doughera@lafayette.edu> wrote:
Wouldn't it also be an option to put #ifdef __GNUC__ at some appropriate place? Probably better just to avoid the construct though. |
From @doughera88On Thu, 7 Jan 2010, Craig A. Berry wrote:
[I've edited the above to what I think is the correct syntax.] Sadly, with gcc-4.1, this now gives me *two* warnings: try.c:2: warning: ignoring #pragma GCC diagnostic I don't know what version of gcc started supporting that construct, but it
-- |
From @kmxDne 7.1.2010 14:50, Andy Dougherty napsal(a):
I agree with Andy. We have to compare: 1) on one hand: (un)convenience of config.h hand editing - deleting 2 2) on the other hand: more than one thousand warnings per each Considering the fact that "/ **/" style is already in place in other -- |
From @steve-m-haykmx wrote on 2010-01-07:
Yes, okay, that sounds fair enough. I hadn't realized before Andy I'll try to apply your patch and update the canned config files in the |
From @steve-m-hay2010/1/8 Steve Hay <SteveHay@planit.com>:
I've now applied your patch and regenerated the canned config files in |
From @steve-m-hayOn Sun Jan 10 16:45:36 2010, steve.m.hay@googlemail.com wrote:
I was just about to close this bug in the light of the above, but I |
@steve-m-hay is that needed to close this? |
These still need editing. I might have time to do a PR over the weekend.
These two claim to have been automatically generated, so could be sufficient to regenerate them?
WinCE support is gone. |
Migrated from rt.perl.org#71852 (status was 'open')
Searchable as RT71852$
The text was updated successfully, but these errors were encountered: