Skip to content
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

CORE/util.h breaks if multiply included (patch) #15944

Closed
p5pRT opened this issue Apr 6, 2017 · 34 comments
Closed

CORE/util.h breaks if multiply included (patch) #15944

p5pRT opened this issue Apr 6, 2017 · 34 comments

Comments

@p5pRT
Copy link

p5pRT commented Apr 6, 2017

Migrated from rt.perl.org#131110 (status was 'resolved')

Searchable as RT131110$

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2017

From james.schneider@db.com

Created by james.schneider@db.com

The header file CORE/util.h breaks if multiply included. This breaks older
modules that include both perl.h and util.h directly. A patch to address this
is included below.

--<patch below>--

Inline Patch
--- util.h.orig 2017-04-06 16:51:50.000000000 +0100
+++ util.h      2017-04-06 16:53:40.000000000 +0100
@@ -8,6 +8,9 @@
  *
  */

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
#ifdef VMS \# define PERL\_FILE\_IS\_ABSOLUTE\(f\) \\   \(\*\(f\) == '/' \\ @​@​ \-232\,3 \+235\,4 @​@​ /\*   \* ex​: set ts=8 sts=4 sw=4 et​:   \*/ \+\#endif /\*PERL\_CORE\_UTIL\_H\_INCLUDED\*/ \-\-\\-\-
Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.24.1:

Configured by mcmefer at Wed Feb 22 15:35:16 GMT 2017.

Summary of my perl5 (revision 5 version 24 subversion 1) configuration:

  Platform:
    osname=linux, osvers=3.0.101-0.47.90-default, archname=x86_64-linux
    uname='linux fraitcf1vd1954 3.0.101-0.47.90-default #1 smp wed oct 19 14:11:00 utc 2016 (56c73f1) x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Dotherlibdirs=/opt/dap/api -Dprefix=/opt/dap/apps/perl-5.24.1'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2',
    optimize='-O2',
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.3.4 [gcc-4_3-branch revision 152973]', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector'
    libpth=/usr/lib64/gcc/x86_64-suse-linux/4.3/include-fixed /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/lib /usr/lib /lib/../
lib64 /usr/lib/../lib64 /lib /lib64 /usr/lib64 /usr/local/lib64
    libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.11.3.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.11.3'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -fstack-protector'


@INC for perl 5.24.1:
    /home/schnjam/perl
    /home/schnjam/perl/lib
    /home/schnjam/perl/lib/5.18.1/x86_64-linux
    /home/schnjam/perl/lib/5.18.1
    /home/schnjam/perl/lib/perl5/x86_64-linux
    /home/schnjam/perl/lib/perl5
    /home/schnjam/perl/lib/site_perl
    /home/schnjam/perl/lib/site_perl/5.18.1/x86_64-linux
    /home/schnjam/perl/lib/site_perl/5.18.1
    /opt/dap/apps/perl-5.24.1/lib/site_perl/5.24.1/x86_64-linux
    /opt/dap/apps/perl-5.24.1/lib/site_perl/5.24.1
    /opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux
    /opt/dap/apps/perl-5.24.1/lib/5.24.1
    /opt/dap/api


Environment for perl 5.24.1:
    HOME=/home/schnjam
    LANG=C
    LANGUAGE (unset)
    LC_ALL=POSIX
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/schnjam/bin:/opt/dap/scripts:/opt/dap/apps/perl/bin:/opt/dap/apps/git/bin:/opt/dap/apps/vim/bin:/opt/dap/apps/apache/bin:/opt/dap/apps/
samba/bin:/opt/dap/apps/monit/bin:/opt/dap/apps/mariadb/bin:/opt/dap/apps/htop/bin:/opt/dap/apps/python/bin:/opt/dap/apps/rsync/bin:/opt/dap/apps/tmux
/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/lib/mit/bin:/usr/lib/mit/sbin
    PERL5ALLLIBS=/home/schnjam/perl /home/schnjam/perl/lib /home/schnjam/perl/lib/5.18.1 /home/schnjam/perl/lib/perl5 /home/schnjam/perl/lib/site_perl
/home/schnjam/perl/lib/site_perl/5.18.1
    PERL5BASE=/home/schnjam/perl
    PERL5BASELIB=/home/schnjam/perl/lib /home/schnjam/perl/lib/5.18.1 /home/schnjam/perl/lib/perl5
    PERL5BASESITELIB=/home/schnjam/perl/lib/site_perl /home/schnjam/perl/lib/site_perl/5.18.1
    PERL5LIB=/home/schnjam/perl:/home/schnjam/perl/lib:/home/schnjam/perl/lib/5.18.1:/home/schnjam/perl/lib/perl5:/home/schnjam/perl/lib/site_perl:/ho
me/schnjam/perl/lib/site_perl/5.18.1
    PERL_BADLANG (unset)
    PERL_MB_OPT=install_base=/home/schnjam/perl
    PERL_MM_OPT=PREFIX=/home/schnjam/perl
    SHELL=/bin/bash



This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

@p5pRT
Copy link
Author

p5pRT commented Apr 7, 2017

From @jkeenan

On Thu, 06 Apr 2017 16​:06​:38 GMT, james.schneider@​db.com wrote​:

This is a bug report for perl from james.schneider@​db.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

The header file CORE/util.h breaks if multiply included. This breaks
older
modules that include both perl.h and util.h directly. A patch to
address this
is included below.

--<patch below>--
--- util.h.orig 2017-04-06 16​:51​:50.000000000 +0100
+++ util.h 2017-04-06 16​:53​:40.000000000 +0100
@​@​ -8,6 +8,9 @​@​
*
*/

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
#ifdef VMS
# define PERL_FILE_IS_ABSOLUTE(f) \
(*(f) == '/'
\
@​@​ -232,3 +235,4 @​@​
/*
* ex​: set ts=8 sts=4 sw=4 et​:
*/
+#endif /*PERL_CORE_UTIL_H_INCLUDED*/
--<patch above>--

Would you be able to (a) provide an example of this failure; and (b) to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Apr 7, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Apr 7, 2017

From james.schneider@db.com

Would you be able to (a) provide an example of this failure; and (b) to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

Unfortunately, when I tried to send the example, it was blocked by the outgoing mailer. Hopefully, the patch makes it through.

It is easy to demonstrate, however​:

1. Create a Perl module skeleton with h2xs (eg, "h2xs -cf -n Examp")
2. Change to your new module directory
3. Add the line '#include "util.h"' after the line '#include "perl.h"' in the .xs file in your module directory.
4. Run "perl Makefile.PL"
5. Run "make"


This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

@p5pRT
Copy link
Author

p5pRT commented Apr 7, 2017

From james.schneider@db.com

utilhfix.patch
--- util.h.orig 2017-04-06 16:51:50.000000000 +0100
+++ util.h      2017-04-06 16:53:40.000000000 +0100
@@ -8,6 +8,9 @@
  *
  */

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
 #ifdef VMS
 #  define PERL_FILE_IS_ABSOLUTE(f) \
        (*(f) == '/'                                                    \
@@ -232,3 +235,4 @@
 /*
  * ex: set ts=8 sts=4 sw=4 et:
  */
+#endif /*PERL_CORE_UTIL_H_INCLUDED*/

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2017

From @jkeenan

On Fri, 07 Apr 2017 23​:22​:13 GMT, james.schneider@​db.com wrote​:

Would you be able to (a) provide an example of this failure; and (b)
to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

Unfortunately, when I tried to send the example, it was blocked by the
outgoing mailer. Hopefully, the patch makes it through.

It is easy to demonstrate, however​:

1. Create a Perl module skeleton with h2xs (eg, "h2xs -cf -n Examp")
2. Change to your new module directory
3. Add the line '#include "util.h"' after the line '#include "perl.h"'
in the .xs file in your module directory.
4. Run "perl Makefile.PL"
5. Run "make"

This is what I got following your instructions.

#####
$ cat Examp.xs
#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "util.h"
#include "XSUB.h"

#include "ppport.h"

MODULE = Examp PACKAGE = Examp

$ perl Makefile.PL && make
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Examp
Writing MYMETA.yml and MYMETA.json
cp lib/Examp.pm blib/lib/Examp.pm
AutoSplitting blib/lib/Examp.pm (blib/lib/auto/Examp)
Running Mkbootstrap for Examp ()
chmod 644 "Examp.bs"
"/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/bin/perl" -MExtUtils​::Command​::MM -e 'cp_nonempty' -- Examp.bs blib/arch/auto/Examp/Examp.bs 644
"/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/bin/perl" "/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/lib/5.24.1/ExtUtils/xsubpp" -typemap '/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/lib/5.24.1/ExtUtils/typemap' Examp.xs > Examp.xsc
Please specify prototyping behavior for Examp.xs (see perlxs manual)
mv Examp.xsc Examp.c
cc -c -I. -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE" Examp.c
rm -f blib/arch/auto/Examp/Examp.so
cc -shared -O2 -L/usr/local/lib -fstack-protector-strong Examp.o -o blib/arch/auto/Examp/Examp.so \
  \
 
chmod 755 blib/arch/auto/Examp/Examp.so
Manifying 1 pod document

$ make test
"/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/bin/perl" -MExtUtils​::Command​::MM -e 'cp_nonempty' -- Examp.bs blib/arch/auto/Examp/Examp.bs 644
PERL_DL_NONLAZY=1 "/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/bin/perl" "-MExtUtils​::Command​::MM" "-MTest​::Harness" "-e" "undef *Test​::Harness​::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Examp.t .. ok
All tests successful.
Files=1, Tests=1, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.03 cusr 0.00 csys = 0.05 CPU)
Result​: PASS
#####

I'm not an XS expert -- but I don't see what's broken. Can you clarify?

Thank you very much.
Jim Keenan

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2017

From @khwilliamson

On 04/07/2017 09​:14 AM, James E Keenan via RT wrote​:

On Thu, 06 Apr 2017 16​:06​:38 GMT, james.schneider@​db.com wrote​:

This is a bug report for perl from james.schneider@​db.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

The header file CORE/util.h breaks if multiply included. This breaks
older
modules that include both perl.h and util.h directly. A patch to
address this
is included below.

--<patch below>--
--- util.h.orig 2017-04-06 16​:51​:50.000000000 +0100
+++ util.h 2017-04-06 16​:53​:40.000000000 +0100
@​@​ -8,6 +8,9 @​@​
*
*/

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
#ifdef VMS
# define PERL_FILE_IS_ABSOLUTE(f) \
(*(f) == '/'
\
@​@​ -232,3 +235,4 @​@​
/*
* ex​: set ts=8 sts=4 sw=4 et​:
*/
+#endif /*PERL_CORE_UTIL_H_INCLUDED*/
--<patch above>--

Would you be able to (a) provide an example of this failure; and (b) to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131110

I think fixing this for 5.26 is a reasonable thing to do.

It is an oversight that the guard is missing from util.h. But we do
have an established pattern in the perl source code for placing this
guard, which spells it differently than this patch. I think we should
stick to our existing pattern. I have attached a patch that does that.
I think it should go into 5.26.

The AUTHORS file needs to also be updated. We have a Jim Schneider in
it, at <jschneid@​netilla.com>. Is that you, and if so, is that email
still valid? Or should we replace it with this one, or add it as an
alternate?

FWIW, when C was younger, I and others tried to get things changed so
that the preprocessor kept track, and only included a header once. But
we were rebuffed because a few people who were involved in maintaining
the compiler used the multiple inclusion to do tricks. So it's left to
just about every project in the world to have to spend effort to put in
the guards.

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2017

From @khwilliamson

0003-Guard-against-nested-util.h-include.patch
From f9f7cfb9bf0d82b16dc925c439ab9975feaf940b Mon Sep 17 00:00:00 2001
From: Jim Schneider <james.schneider@db.com>
Date: Sat, 8 Apr 2017 10:34:14 -0600
Subject: [PATCH 3/3] Guard against nested util.h #include

---
 util.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/util.h b/util.h
index 8f4171b..6230f40 100644
--- a/util.h
+++ b/util.h
@@ -8,6 +8,9 @@
  *
  */
 
+#ifndef UTIL_H /* Guard against nested #inclusion */
+#define UTIL_H
+
 #ifdef VMS
 #  define PERL_FILE_IS_ABSOLUTE(f) \
 	(*(f) == '/'							\
@@ -236,6 +239,8 @@ means arg not present, 1 is empty string/null byte */
             ((char *) memmem(big, bigend - big, little, lend - little))
 #endif
 
+#endif  /* UTIL_H */
+
 /*
  * ex: set ts=8 sts=4 sw=4 et:
  */
-- 
2.7.4

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2017

From @xsawyerx

On 04/08/2017 06​:45 PM, Karl Williamson wrote​:

On 04/07/2017 09​:14 AM, James E Keenan via RT wrote​:

On Thu, 06 Apr 2017 16​:06​:38 GMT, james.schneider@​db.com wrote​:

This is a bug report for perl from james.schneider@​db.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

The header file CORE/util.h breaks if multiply included. This breaks
older
modules that include both perl.h and util.h directly. A patch to
address this
is included below.

--<patch below>--
--- util.h.orig 2017-04-06 16​:51​:50.000000000 +0100
+++ util.h 2017-04-06 16​:53​:40.000000000 +0100
@​@​ -8,6 +8,9 @​@​
*
*/

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
#ifdef VMS
# define PERL_FILE_IS_ABSOLUTE(f) \
(*(f) == '/'
\
@​@​ -232,3 +235,4 @​@​
/*
* ex​: set ts=8 sts=4 sw=4 et​:
*/
+#endif /*PERL_CORE_UTIL_H_INCLUDED*/
--<patch above>--

Would you be able to (a) provide an example of this failure; and (b)
to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131110

I think fixing this for 5.26 is a reasonable thing to do.

This seems innocuous enough.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @iabyn

On Sun, Apr 09, 2017 at 08​:16​:19PM +0200, Sawyer X wrote​:

On 04/08/2017 06​:45 PM, Karl Williamson wrote​:

On 04/07/2017 09​:14 AM, James E Keenan via RT wrote​:

On Thu, 06 Apr 2017 16​:06​:38 GMT, james.schneider@​db.com wrote​:

This is a bug report for perl from james.schneider@​db.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

The header file CORE/util.h breaks if multiply included. This breaks
older
modules that include both perl.h and util.h directly. A patch to
address this
is included below.

--<patch below>--
--- util.h.orig 2017-04-06 16​:51​:50.000000000 +0100
+++ util.h 2017-04-06 16​:53​:40.000000000 +0100
@​@​ -8,6 +8,9 @​@​
*
*/

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
#ifdef VMS
# define PERL_FILE_IS_ABSOLUTE(f) \
(*(f) == '/'
\
@​@​ -232,3 +235,4 @​@​
/*
* ex​: set ts=8 sts=4 sw=4 et​:
*/
+#endif /*PERL_CORE_UTIL_H_INCLUDED*/
--<patch above>--

Would you be able to (a) provide an example of this failure; and (b)
to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131110

I think fixing this for 5.26 is a reasonable thing to do.

This seems innocuous enough.

Except that util.h is a fairly common name, and I could imagine UTIL_H
clashing with something else.

Indeed on my platform, these both exist​:

  /usr/include/ldns/util.h
  /usr/include/sepol/policydb/util.h

and the first has

  #ifndef _UTIL_H
  #define _UTIL_H

So perhaps leave till 5.27?

I'm somewhat surprised that this is causing an issue for the OP​: perl.h
has #included util.h since 5.000, and util.h has had content in it since
about 5.6.0 which would give compilation errors if double-included.
So this must be for an XS module which hasn't worked since 5.6.0 was
released?

--
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From james.schneider@db.com

From​: James E Keenan via RT [mailto​:perlbug-followup@​perl.org]

This is what I got following your instructions.
--<stuff omitted>--
cc -c -I. -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE" Examp.c
rm -f blib/arch/auto/Examp/Examp.so

The version of Examp.xs you created matches mine. This is where stuff breaks on my system. This line and the following, when running "make", gives me the results​:

cc -c -I. -fwrapv -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE" Examp.c
In file included from Examp.xs​:6​:
/opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE/util.h​:71​: error​: redefinition of typedef 'perl_drand48_t'
/opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE/util.h​:71​: error​: previous declaration of 'perl_drand48_t' was here
make​: *** [Examp.o] Error 1

My guess is triggering this bug is compiler-dependent.


This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From james.schneider@db.com

From​: karl williamson via RT [mailto​:perlbug-followup@​perl.org]
Sent​: Saturday, April 08, 2017 12​:47 PM

I think fixing this for 5.26 is a reasonable thing to do.

It is an oversight that the guard is missing from util.h. But we do have an
established pattern in the perl source code for placing this guard, which
spells it differently than this patch. I think we should stick to our
existing pattern. I have attached a patch that does that.
I think it should go into 5.26.

I have no particular attachment to that inclusion guard - I was just trying to get an old module to compile with new perl, so I used something I was certain wouldn't clash elsewhere.

The AUTHORS file needs to also be updated. We have a Jim Schneider in it, at
<jschneid@​netilla.com>. Is that you, and if so, is that email still valid? Or
should we replace it with this one, or add it as an alternate?

Yes, this was my email address at a former employer. I no longer have access to it, and I would be surprised if you could even send mail to it successfully.

FWIW, when C was younger, I and others tried to get things changed so that the
preprocessor kept track, and only included a header once. But we were rebuffed
because a few people who were involved in maintaining the compiler used the
multiple inclusion to do tricks. So it's left to just about every project in
the world to have to spend effort to put in the guards.

Kind of off topic but ... any idea what those "tricks" were? Are any of these source files still in use?


This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From james.schneider@db.com

From​: Dave Mitchell via RT [mailto​:perlbug-followup@​perl.org]
Sent​: Monday, April 10, 2017 7​:20 AM

Except that util.h is a fairly common name, and I could imagine UTIL_H clashing with something else.

Indeed on my platform, these both exist​:

/usr/include/ldns/util.h
/usr/include/sepol/policydb/util.h

and the first has

#ifndef _UTIL_H
#define _UTIL_H

So perhaps leave till 5.27?

I can confirm that "util.h" from the Perl 5.24.1 distribution is being included twice​:

In file included from Examp.xs​:5​:
/opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE/util.h​:71​: error​: redefinition of typedef 'perl_drand48_t'
/opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE/util.h​:71​: error​: previous declaration of 'perl_drand48_t' was here

I'm somewhat surprised that this is causing an issue for the OP​: perl.h has
#included util.h since 5.000, and util.h has had content in it since about 5.6.0
which would give compilation errors if double-included.

So this must be for an XS module which hasn't worked since 5.6.0 was released?

Not quite true. The typedef for perl_drand48_t showed up after 5.18.1, and the double inclusion of this typedef is what's causing problems; when I revert to Perl 5.18.1, I can build it without error.


This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @Leont

On Mon, Apr 10, 2017 at 4​:00 PM, James Schneider <james.schneider@​db.com> wrote​:

From​: karl williamson via RT [mailto​:perlbug-followup@​perl.org]
Sent​: Saturday, April 08, 2017 12​:47 PM

Kind of off topic but ... any idea what those "tricks" were?

#define FOO something
#include "foo.h"
#undef FOO

#define FOO something_else
#include "foo.h"
#undef FOO

Leon

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @jkeenan

On Mon, 10 Apr 2017 14​:07​:20 GMT, james.schneider@​db.com wrote​:

From​: James E Keenan via RT [mailto​:perlbug-followup@​perl.org]

This is what I got following your instructions.
--<stuff omitted>--
cc -c -I. -fwrapv -fno-strict-aliasing -pipe -fstack-protector-
strong -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\"
-fPIC "-I/home/jkeenan/perl5/perlbrew/perls/perl-
5.24.1/lib/5.24.1/x86_64-linux/CORE" Examp.c
rm -f blib/arch/auto/Examp/Examp.so

The version of Examp.xs you created matches mine. This is where stuff
breaks on my system. This line and the following, when running
"make", gives me the results​:

cc -c -I. -fwrapv -fno-strict-aliasing -pipe -fstack-protector
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2
-DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/opt/dap/apps/perl-
5.24.1/lib/5.24.1/x86_64-linux/CORE" Examp.c
In file included from Examp.xs​:6​:
/opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE/util.h​:71​:
error​: redefinition of typedef 'perl_drand48_t'
/opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE/util.h​:71​:
error​: previous declaration of 'perl_drand48_t' was here
make​: *** [Examp.o] Error 1

My guess is triggering this bug is compiler-dependent.

Well, we're both using gcc but your version is much older than mine. Assuming the perl -V attached to your first post is correct, you're using​:

#####
ccversion='', gccversion='4.3.4 [gcc-4_3-branch revision 152973]', gccosandvers=''
#####

I'm using​:

#####
$ perl -V | grep ccversion
  ccversion='', gccversion='5.4.0 20160609', gccosandvers=''
#####

Would you be able to try this with a more recent version of gcc?

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From james.schneider@db.com

From​: James E Keenan via RT [mailto​:perlbug-followup@​perl.org]
Sent​: Monday, April 10, 2017 10​:30 AM

Well, we're both using gcc but your version is much older than mine. Assuming
the perl -V attached to your first post is correct, you're using​:

#####
ccversion='', gccversion='4.3.4 [gcc-4_3-branch revision 152973]',
gccosandvers=''
#####

I'm using​:

#####
$ perl -V | grep ccversion
ccversion='', gccversion='5.4.0 20160609', gccosandvers=''
#####

Would you be able to try this with a more recent version of gcc?

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

Unfortunately, I can't upgrade the compiler. At least, not without months of meetings and endless reams of paperwork.

Can you run your cc command line as given by make, substituting "-E" for the "-c", and then grep for "typedef.*perl_drand48_t;"? On my system, this looks like​:

$ cc -E -I. -fwrapv -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -fPIC "-I/opt/dap/apps/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE" Examp.c | grep -n 'typedef.*perl_drand48_t;'
11129​:typedef unsigned long perl_drand48_t;
18702​:typedef unsigned long perl_drand48_t;

If it only gives you a single line, there's something about your setup that's preventing the multiple typedef from occurring. If it gives you two, gcc 5 is ignoring what the C99 standard indicates should be an error. But I haven't read the more recent standard, so that could be okay now.


This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @khwilliamson

On 04/10/2017 05​:18 AM, Dave Mitchell wrote​:

On Sun, Apr 09, 2017 at 08​:16​:19PM +0200, Sawyer X wrote​:

On 04/08/2017 06​:45 PM, Karl Williamson wrote​:

On 04/07/2017 09​:14 AM, James E Keenan via RT wrote​:

On Thu, 06 Apr 2017 16​:06​:38 GMT, james.schneider@​db.com wrote​:

This is a bug report for perl from james.schneider@​db.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

The header file CORE/util.h breaks if multiply included. This breaks
older
modules that include both perl.h and util.h directly. A patch to
address this
is included below.

--<patch below>--
--- util.h.orig 2017-04-06 16​:51​:50.000000000 +0100
+++ util.h 2017-04-06 16​:53​:40.000000000 +0100
@​@​ -8,6 +8,9 @​@​
*
*/

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
#ifdef VMS
# define PERL_FILE_IS_ABSOLUTE(f) \
(*(f) == '/'
\
@​@​ -232,3 +235,4 @​@​
/*
* ex​: set ts=8 sts=4 sw=4 et​:
*/
+#endif /*PERL_CORE_UTIL_H_INCLUDED*/
--<patch above>--

Would you be able to (a) provide an example of this failure; and (b)
to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131110

I think fixing this for 5.26 is a reasonable thing to do.

This seems innocuous enough.

Except that util.h is a fairly common name, and I could imagine UTIL_H
clashing with something else.

Indeed on my platform, these both exist​:

/usr/include/ldns/util\.h
/usr/include/sepol/policydb/util\.h

and the first has

\#ifndef \_UTIL\_H
\#define \_UTIL\_H

So perhaps leave till 5.27?

Note that this doesn't conflict with our paradigm since it begins with
an underscore. But your point is well taken. Our paradigm probably
should shift to

#ifndef PERL_UTIL_H
etc.

We could do this just for util.h in 5.26; and change the rest in 5.27.

I'm somewhat surprised that this is causing an issue for the OP​: perl.h
has #included util.h since 5.000, and util.h has had content in it since
about 5.6.0 which would give compilation errors if double-included.
So this must be for an XS module which hasn't worked since 5.6.0 was
released?

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2017

From @Tux

On Mon, 10 Apr 2017 10​:39​:00 -0600, Karl Williamson
<public@​khwilliamson.com> wrote​:

Indeed on my platform, these both exist​:

/usr/include/ldns/util\.h
/usr/include/sepol/policydb/util\.h

and the first has

\#ifndef \_UTIL\_H
\#define \_UTIL\_H

So perhaps leave till 5.27?

Note that this doesn't conflict with our paradigm since it begins with
an underscore. But your point is well taken. Our paradigm probably
should shift to

#ifndef PERL_UTIL_H
etc.

+1!

We could do this just for util.h in 5.26; and change the rest in 5.27.

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using perl5.00307 .. 5.25 porting perl5 on HP-UX, AIX, and openSUSE
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2017

From @demerphq

On 10 April 2017 at 18​:39, Karl Williamson <public@​khwilliamson.com> wrote​:

On 04/10/2017 05​:18 AM, Dave Mitchell wrote​:

On Sun, Apr 09, 2017 at 08​:16​:19PM +0200, Sawyer X wrote​:

On 04/08/2017 06​:45 PM, Karl Williamson wrote​:

On 04/07/2017 09​:14 AM, James E Keenan via RT wrote​:

On Thu, 06 Apr 2017 16​:06​:38 GMT, james.schneider@​db.com wrote​:

This is a bug report for perl from james.schneider@​db.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

The header file CORE/util.h breaks if multiply included. This breaks
older
modules that include both perl.h and util.h directly. A patch to
address this
is included below.

--<patch below>--
--- util.h.orig 2017-04-06 16​:51​:50.000000000 +0100
+++ util.h 2017-04-06 16​:53​:40.000000000 +0100
@​@​ -8,6 +8,9 @​@​
*
*/

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
#ifdef VMS
# define PERL_FILE_IS_ABSOLUTE(f) \
(*(f) == '/'
\
@​@​ -232,3 +235,4 @​@​
/*
* ex​: set ts=8 sts=4 sw=4 et​:
*/
+#endif /*PERL_CORE_UTIL_H_INCLUDED*/
--<patch above>--

Would you be able to (a) provide an example of this failure; and (b)
to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131110

I think fixing this for 5.26 is a reasonable thing to do.

This seems innocuous enough.

Except that util.h is a fairly common name, and I could imagine UTIL_H
clashing with something else.

Indeed on my platform, these both exist​:

/usr/include/ldns/util\.h
/usr/include/sepol/policydb/util\.h

and the first has

\#ifndef \_UTIL\_H
\#define \_UTIL\_H

So perhaps leave till 5.27?

Note that this doesn't conflict with our paradigm since it begins with an
underscore. But your point is well taken. Our paradigm probably should
shift to

#ifndef PERL_UTIL_H
etc.

_PERL_UTIL_H

would fit nicer with the previous pattern. And doesn't look like a
normal PERL define.

Yves

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2017

From @khwilliamson

On 04/11/2017 04​:13 AM, demerphq wrote​:

On 10 April 2017 at 18​:39, Karl Williamson <public@​khwilliamson.com> wrote​:

On 04/10/2017 05​:18 AM, Dave Mitchell wrote​:

On Sun, Apr 09, 2017 at 08​:16​:19PM +0200, Sawyer X wrote​:

On 04/08/2017 06​:45 PM, Karl Williamson wrote​:

On 04/07/2017 09​:14 AM, James E Keenan via RT wrote​:

On Thu, 06 Apr 2017 16​:06​:38 GMT, james.schneider@​db.com wrote​:

This is a bug report for perl from james.schneider@​db.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

The header file CORE/util.h breaks if multiply included. This breaks
older
modules that include both perl.h and util.h directly. A patch to
address this
is included below.

--<patch below>--
--- util.h.orig 2017-04-06 16​:51​:50.000000000 +0100
+++ util.h 2017-04-06 16​:53​:40.000000000 +0100
@​@​ -8,6 +8,9 @​@​
*
*/

+#ifndef PERL_CORE_UTIL_H_INCLUDED
+#define PERL_CORE_UTIL_H_INCLUDED
+
#ifdef VMS
# define PERL_FILE_IS_ABSOLUTE(f) \
(*(f) == '/'
\
@​@​ -232,3 +235,4 @​@​
/*
* ex​: set ts=8 sts=4 sw=4 et​:
*/
+#endif /*PERL_CORE_UTIL_H_INCLUDED*/
--<patch above>--

Would you be able to (a) provide an example of this failure; and (b)
to provide the patch as an email attachment (rather than inline)?

Thank you very much.
Jim Keenan

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131110

I think fixing this for 5.26 is a reasonable thing to do.

This seems innocuous enough.

Except that util.h is a fairly common name, and I could imagine UTIL_H
clashing with something else.

Indeed on my platform, these both exist​:

/usr/include/ldns/util\.h
/usr/include/sepol/policydb/util\.h

and the first has

\#ifndef \_UTIL\_H
\#define \_UTIL\_H

So perhaps leave till 5.27?

Note that this doesn't conflict with our paradigm since it begins with an
underscore. But your point is well taken. Our paradigm probably should
shift to

#ifndef PERL_UTIL_H
etc.

_PERL_UTIL_H

would fit nicer with the previous pattern. And doesn't look like a
normal PERL define.

The previous pattern would have been UTIL_H. But I agree that a leading
underscore is better.

Yves

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2017

From zefram@fysh.org

Karl Williamson wrote​:

The previous pattern would have been UTIL_H. But I agree that a leading
underscore is better.

Adding a leading underscore would encroach on the range of identifiers
that is reserved to the C implementation. (Leading underscore-capital
and leading double underscore are reserved.) We mostly avoid that kind
of name at present. It would be better to make the name distinctive to
Perl, and to stay in the range of names permitted to C users.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Apr 13, 2017

From @iabyn

On Tue, Apr 11, 2017 at 07​:09​:06PM +0100, Zefram wrote​:

Karl Williamson wrote​:

The previous pattern would have been UTIL_H. But I agree that a leading
underscore is better.

Adding a leading underscore would encroach on the range of identifiers
that is reserved to the C implementation. (Leading underscore-capital
and leading double underscore are reserved.) We mostly avoid that kind
of name at present. It would be better to make the name distinctive to
Perl, and to stay in the range of names permitted to C users.

We currently seem to have​:

$ grep 'ifndef.*_H\b' *.h
dquote_inline.h​:#ifndef DQUOTE_INLINE_H /* Guard against nested #inclusion */
handy.h​:#ifndef HANDY_H /* Guard against nested #inclusion */
hv_func.h​:#ifndef PERL_SEEN_HV_FUNC_H /* compile once */
malloc_ctl.h​:#ifndef MALLOC_CTL_H
perlio.h​:#ifndef _PERLIO_H
perliol.h​:#ifndef _PERLIOL_H
reentr.h​:#ifndef REENTR_H
time64_config.h​:#ifndef TIME64_CONFIG_H
time64.h​:#ifndef TIME64_H
XSUB.h​:#ifndef _INC_PERL_XSUB_H

so quite a mishmash.
I agree that standardising on

  PERL_<NAME>_H

seems the least-worst option.

--
Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip

@p5pRT
Copy link
Author

p5pRT commented Apr 13, 2017

From @mauke

Am 11.04.2017 um 20​:09 schrieb Zefram​:

Karl Williamson wrote​:

The previous pattern would have been UTIL_H. But I agree that a leading
underscore is better.

Adding a leading underscore would encroach on the range of identifiers
that is reserved to the C implementation. (Leading underscore-capital
and leading double underscore are reserved.) We mostly avoid that kind
of name at present. It would be better to make the name distinctive to
Perl, and to stay in the range of names permitted to C users.

Leading underscore is reserved but trailing underscore isn't. Personally
I'm quite fond of names like PERL_UTIL_H_.
</bikeshed>

--
Lukas Mai <plokinom@​gmail.com>

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2017

From @demerphq

On 13 April 2017 at 20​:33, Lukas Mai <plokinom@​gmail.com> wrote​:

Am 11.04.2017 um 20​:09 schrieb Zefram​:

Karl Williamson wrote​:

The previous pattern would have been UTIL_H. But I agree that a leading
underscore is better.

Adding a leading underscore would encroach on the range of identifiers
that is reserved to the C implementation. (Leading underscore-capital
and leading double underscore are reserved.) We mostly avoid that kind
of name at present. It would be better to make the name distinctive to
Perl, and to stay in the range of names permitted to C users.

Leading underscore is reserved but trailing underscore isn't. Personally I'm
quite fond of names like PERL_UTIL_H_.
</bikeshed>

FWIW I like this. I like that it doesnt look like a normal perl define.

But this whole leading underbar thing worries me just a touch. I am
pretty sure i have added macros to Perl with leading underbars and all
caps. Probably in every combination that is technically reserved. Do
we have to do an audit of all our macros to make sure we clean this
up?

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2017

From zefram@fysh.org

demerphq wrote​:

we have to do an audit of all our macros to make sure we clean this
up?

Might be worth doing. Turns out there are more than I thought.
Here's the starting point on identifiers used by Perl​:

$ perl -lwe '$/=undef; while(<>) { s/\\\n//g; s/^[ \t]*#[ \t]*include[^\n]*\n//mg; s#(["\x27])(?​:[^"\x27\\]++|(?!\1)["\x27]|\\.)*\1|/\*.*?\*/# #sg; $i{$1} = 1 while /(?<![0-9A-Z_a-z])([A-Z_a-z][0-9A-Z_a-z]*)(?![0-9A-Z_a-z])/g; } print for sort keys %i' *.[ch]

There are other reserved categories of identifier too, not just the ones
beginning with underscore. Some are reserved when used with external
linkage but not as macros or other usages. If we're going to audit,
might as well cover them all​:

http​://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html

-zefram

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2017

From zefram@fysh.org

Further thought​: after audit and cleanup we ought to enforce that we
do not encroach further on reserved identifier space, with an automated
test that has a list of approved exceptions.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Apr 16, 2017

From @iabyn

On Fri, Apr 14, 2017 at 08​:31​:31AM +0200, demerphq wrote​:

On 13 April 2017 at 20​:33, Lukas Mai <plokinom@​gmail.com> wrote​:

Am 11.04.2017 um 20​:09 schrieb Zefram​:

Karl Williamson wrote​:

The previous pattern would have been UTIL_H. But I agree that a leading
underscore is better.

Adding a leading underscore would encroach on the range of identifiers
that is reserved to the C implementation. (Leading underscore-capital
and leading double underscore are reserved.) We mostly avoid that kind
of name at present. It would be better to make the name distinctive to
Perl, and to stay in the range of names permitted to C users.

Leading underscore is reserved but trailing underscore isn't. Personally I'm
quite fond of names like PERL_UTIL_H_.
</bikeshed>

FWIW I like this. I like that it doesnt look like a normal perl define.

I've made an Executive Decision and gone with PERL_UTIL_H_, in
v5.25.11-56-gab1d79f.

We can change the remaining .h files to match after 5.26.0 is out.

--
This is a great day for France!
  -- Nixon at Charles De Gaulle's funeral

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2017

From @khwilliamson

On 04/16/2017 02​:00 PM, Dave Mitchell wrote​:

On Fri, Apr 14, 2017 at 08​:31​:31AM +0200, demerphq wrote​:

On 13 April 2017 at 20​:33, Lukas Mai <plokinom@​gmail.com> wrote​:

Am 11.04.2017 um 20​:09 schrieb Zefram​:

Karl Williamson wrote​:

The previous pattern would have been UTIL_H. But I agree that a leading
underscore is better.

Adding a leading underscore would encroach on the range of identifiers
that is reserved to the C implementation. (Leading underscore-capital
and leading double underscore are reserved.) We mostly avoid that kind
of name at present. It would be better to make the name distinctive to
Perl, and to stay in the range of names permitted to C users.

Leading underscore is reserved but trailing underscore isn't. Personally I'm
quite fond of names like PERL_UTIL_H_.
</bikeshed>

FWIW I like this. I like that it doesnt look like a normal perl define.

I've made an Executive Decision and gone with PERL_UTIL_H_, in
v5.25.11-56-gab1d79f.

You patched util.c, not util.h.

We can change the remaining .h files to match after 5.26.0 is out.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2017

From @iabyn

On Mon, Apr 17, 2017 at 04​:21​:29PM -0600, Karl Williamson wrote​:

You patched util.c, not util.h.

D'oh!!

fixed with v5.25.11-60-g28922db

--
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"

@p5pRT
Copy link
Author

p5pRT commented Apr 20, 2017

From @khwilliamson

On Tue, 18 Apr 2017 05​:00​:05 -0700, davem wrote​:

On Mon, Apr 17, 2017 at 04​:21​:29PM -0600, Karl Williamson wrote​:

You patched util.c, not util.h.

D'oh!!

fixed with v5.25.11-60-g28922db

I'm working on a patch for 5.27 for the remainder of these. I'll close this ticket, as what it is asking for is now fixed in blead.

I notice that a bunch of headers, like sv.h, av.h, ... don't have guards.
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Apr 20, 2017

From [Unknown Contact. See original ticket]

On Tue, 18 Apr 2017 05​:00​:05 -0700, davem wrote​:

On Mon, Apr 17, 2017 at 04​:21​:29PM -0600, Karl Williamson wrote​:

You patched util.c, not util.h.

D'oh!!

fixed with v5.25.11-60-g28922db

I'm working on a patch for 5.27 for the remainder of these. I'll close this ticket, as what it is asking for is now fixed in blead.

I notice that a bunch of headers, like sv.h, av.h, ... don't have guards.
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Apr 20, 2017

@khwilliamson - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented May 30, 2017

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.26.0, this and 210 other issues have been
resolved.

Perl 5.26.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.26.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT
Copy link
Author

p5pRT commented May 30, 2017

@khwilliamson - Status changed from 'pending release' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant