[perl #117969] use POSIX emits multiple warnings if used after "Cwd"

[Linda Walsh]

# New Ticket Created by Linda Walsh
# Please include the string: [perl #117969]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=117969 >



This is a bug report for perl from perl-d...@tlinx.org,
generated with the help of perlbug 1.39 running under perl 5.16.2.


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

There are sorta 2 problems here with the POSIX module -- they are
related, so figure 1 bug report is sufficient.

I was trying to "use POSIX" and got multiple warnings in my
program:
Prototype mismatch: sub main::CLOCKS_PER_SEC: none vs () at /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/POSIX.pm line 30.
POSIX::import('POSIX') called at ./remove-oldver-rpms-in-dir.pl line 786
main::BEGIN() called at ./remove-oldver-rpms-in-dir.pl line 786
eval {...} called at ./remove-oldver-rpms-in-dir.pl line 786
Subroutine main::clock redefined at /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/POSIX.pm line 30.
POSIX::import('POSIX') called at ./remove-oldver-rpms-in-dir.pl line 786
main::BEGIN() called at ./remove-oldver-rpms-in-dir.pl line 786
eval {...} called at ./remove-oldver-rpms-in-dir.pl line 786
Prototype mismatch: sub main::clock () vs none at /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/POSIX.pm line 30.
POSIX::import('POSIX') called at ./remove-oldver-rpms-in-dir.pl line 786
main::BEGIN() called at ./remove-oldver-rpms-in-dir.pl line 786
eval {...} called at ./remove-oldver-rpms-in-dir.pl line 786
Subroutine main::getcwd redefined at /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/POSIX.pm line 30.
POSIX::import('POSIX') called at ./remove-oldver-rpms-in-dir.pl line 786
main::BEGIN() called at ./remove-oldver-rpms-in-dir.pl line 786
eval {...} called at ./remove-oldver-rpms-in-dir.pl line 786

I spent an a few hours tracking down why. This
minimal test case shows only 1 warning, but I think it might get the
principle across (if you want the longer program I'll be happy to supply
it).
----
#!/usr/bin/perl -w
use Cwd qw(getcwd cwd abs_path realpath);
{
no warnings; use POSIX; #>& /dev/null!
}
---
Gives:
Subroutine main::getcwd redefined at /tmp/postest.pl line 4.

That's the first problem -- that there are any warnings.


Second -- is it's not easy to shut them off.

For one reason or another, the
'no warnings' in front of the
'use POSIX' doesn't turn them off.

...(played around some as writing this...)

It seems "-w" on line 1 is overriding "no warnings in *THIS* program.
I say 'THIS', because I have multiple other programs with the same
construct that work as one would expect: (warnings about something are
silenced in the lexical scope).

I'm not sure why it would be different here but that's
the 2nd bug 'no warnings' isn't working here.




[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=medium
---
This perlbug was built using Perl 5.16.2 - Fri Feb 15 01:17:37 UTC 2013
It is being executed now by Perl 5.16.2 - Fri Feb 15 01:12:05 UTC 2013.

Site configuration information for perl 5.16.2:

Configured by abuild at Fri Feb 15 01:12:05 UTC 2013.

Summary of my perl5 (revision 5 version 16 subversion 2) configuration:

Platform:
osname=linux, osvers=3.4.6-2.10-default, archname=x86_64-linux-thread-multi
uname='linux build34 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector'
ccversion='', gccversion='4.7.2 20130108 [gcc-4_7-branch revision 195012]', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
libpth=/lib64 /usr/lib64 /usr/local/lib64
libs=-lm -ldl -lcrypt -lpthread
perllibs=-lm -ldl -lcrypt -lpthread
libc=/lib64/libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.17'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector'

Locally applied patches:


---
@INC for perl 5.16.2:
/home/law/bin/lib
/usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.16.2
/usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.16.2
/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi
/usr/lib/perl5/5.16.2
/usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.16.2
/usr/lib/perl5/site_perl
.

---
Environment for perl 5.16.2:
HOME=/home/law
LANG=en_US.UTF-8
LANGUAGE (unset)
LC_COLLATE=C
LC_CTYPE=en_US.UTF-8
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=.:/home/law/bin/lib:/sbin:/usr/local/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib
PERL5OPT=-CSA -I/home/law/bin/lib
PERL_BADLANG (unset)
SHELL=/bin/bash

[Lukas Mai]

On 12.05.2013 03:02, Linda Walsh (via RT) wrote:
> # New Ticket Created by Linda Walsh
> # Please include the string: [perl #117969]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=117969 >
>
>
>
> This is a bug report for perl from perl-d...@tlinx.org,
> generated with the help of perlbug 1.39 running under perl 5.16.2.
>
>
> -----------------------------------------------------------------
> [Please describe your issue here]
>
> There are sorta 2 problems here with the POSIX module -- they are
> related, so figure 1 bug report is sufficient.

> I spent an a few hours tracking down why. This
> minimal test case shows only 1 warning, but I think it might get the
> principle across (if you want the longer program I'll be happy to supply
> it).
> ----
> #!/usr/bin/perl -w
> use Cwd qw(getcwd cwd abs_path realpath);
> {
> no warnings; use POSIX; #>& /dev/null!
> }
> ---
> Gives:
> Subroutine main::getcwd redefined at /tmp/postest.pl line 4.
>
> That's the first problem -- that there are any warnings.

No, that's normal. You're loading two modules, each of which redefines
main::getcwd().

>
> Second -- is it's not easy to shut them off.

It's trivial to shut them off: Just remove -w.
There is no reason to use -w in any perl that supports 'use warnings'
(i.e. 5.6 or better).

> For one reason or another, the
> 'no warnings' in front of the
> 'use POSIX' doesn't turn them off.

The reason is that 'use warnings'/'no warnings' is lexical, i.e. it only
affects code in the current block. The actual subroutine redefinition,
however, happens in the POSIX module (or probably in Exporter, even).
There's no way to influence warnings from other modules via 'use
warnings'/'no warnings'.

But there is a way to turn on warnings globally, even for modules that
don't expect them to be active: the -w switch.

> ...(played around some as writing this...)
>
> It seems "-w" on line 1 is overriding "no warnings in *THIS* program.
> I say 'THIS', because I have multiple other programs with the same
> construct that work as one would expect: (warnings about something are
> silenced in the lexical scope).
>
> I'm not sure why it would be different here but that's
> the 2nd bug 'no warnings' isn't working here.

In conclusion: You're describing your mistaken interpretation of what's
going on, not what's going on. In fact, it could be argued that the
warning is correct as getcwd actually gets redefined. I guess that would
be a feature request for Exporter ... ?

--
Lukas Mai <plok...@gmail.com>

[Aristotle Pagaltzis]

* Linda Walsh <perlbug-...@perl.org> [2013-05-12 03:05]:

> #!/usr/bin/perl -w
> use Cwd qw(getcwd cwd abs_path realpath);
> {
> no warnings; use POSIX; #>& /dev/null!
> }
> ---
> Gives:
> Subroutine main::getcwd redefined at /tmp/postest.pl line 4.
>
> That's the first problem -- that there are any warnings.

The warning *is* not the problem, the warning tells you *about* the
problem. You explicitly imported `getcwd` from Cwd, then used POSIX
which also exports `getcwd` by default. Thus you overwrote the one you
asked for with another you got implicitly. Now it so happens that the
new `getcwd` you got is functionally identical to the one you lost and
your program will therefore work either way. But there is no inherent
reason for a collision to be harmless like this, therefore the warning
is not noise that one should like to strangle but a heads-up to heed.

The correct fix for your problem is to cease asking either Cwd or POSIX
for `getcwd`, which in the case of POSIX is most feasibly and sanely
achieved by asking POSIX to export only the functions you will require.
(In the name of convenience, its default export list is *huge* and full
of stuff you will never use.)

[Linda Walsh via RT]

On Sat May 11 23:17:18 2013, plok...@gmail.com wrote:
> No, that's normal. You're loading two modules, each of which redefines
> main::getcwd().

---
The idea that that the POSIX module would blindly redefine common
functions is entirely a short-coming in the POSIX module.

>
> >
> > Second -- is it's not easy to shut them off.
>
> It's trivial to shut them off: Just remove -w.
> There is no reason to use -w in any perl that supports 'use warnings'
> (i.e. 5.6 or better).

----
It turns out that putting the CWD module 2nd silences the problem
as it doesn't have the same bug as the POSIX module. If the warning
happened in both instances, I'd say you have a point. But the fact that
it doesn't means that the POSIX module it redefining things that are
already defined when it has not been asked to.

I usually support modules, like POSIX, exporting all of their
needed routines, but with large export lists, it becomes even more
important not to do so blindly, but check to see if the module is
already defined in the user's context and only issue warnings for those
modules that the user has specifically requested
(as in use POSIX qw(getcwd) ).

That's a reasonable approach.

Second -- I clearly stated that in most of my programs putting
a "no warnings" before something that is emitting warnings HAS
overridden the specification of "-w" on the interpreter line.

To go off and tell me why that doesn't work flied in the face of plenty
of other examples.

Should I report the 20-score or more cases where it does work as bugs?

> > For one reason or another, the
> > 'no warnings' in front of the
> > 'use POSIX' doesn't turn them off.
>
> The reason is that 'use warnings'/'no warnings' is lexical, i.e. it only
> affects code in the current block. The actual subroutine redefinition,
> however, happens in the POSIX module (or probably in Exporter, even).
> There's no way to influence warnings from other modules via 'use
> warnings'/'no warnings'.

---

See above... I'm now wondering about the majority of the cases
where it does work... and wondering why...


FWIW.. in my usage case, require POSIX was all that was needed,
I didn't rely on any exported names (as I didn't know that they were
exported let alone, that one of them conflicted with Cwd or that they
would stomp on the namespace).

The fact that it stomps on namespace and issues warnings for things as
it overwrites things that have not been explicitly imported seems an
unfriendly default for a CORE module, no?





---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=117969

[Nicholas Clark]

On Sun, May 12, 2013 at 10:10:49AM -0700, Linda Walsh via RT wrote:
> On Sat May 11 23:17:18 2013, plok...@gmail.com wrote:
> > No, that's normal. You're loading two modules, each of which redefines
> > main::getcwd().
> ---
> The idea that that the POSIX module would blindly redefine common
> functions is entirely a short-coming in the POSIX module.

Depends on one's idea of common. Both modules are *documented* as defining
a routine with the same name, and, as it turns out, both have exported it
by default since 5.000.

> It turns out that putting the CWD module 2nd silences the problem
> as it doesn't have the same bug as the POSIX module. If the warning
> happened in both instances, I'd say you have a point. But the fact that
> it doesn't means that the POSIX module it redefining things that are
> already defined when it has not been asked to.

No, it is doing exactly what you asked it to do - by default it exports
everything. It happens that the two modules have conflicting exports.
This will not be the only case of it.

> Should I report the 20-score or more cases where it does work as bugs?

Depends if they are actually bugs. This is working as documented. That it's
documented behaviour is not what you want or expect is *not* a bug.

If the 20 are all documented behaviour, then generating 20 bugs which someone
has to reject is not useful.

> FWIW.. in my usage case, require POSIX was all that was needed,
> I didn't rely on any exported names (as I didn't know that they were
> exported let alone, that one of them conflicted with Cwd or that they
> would stomp on the namespace).
>
> The fact that it stomps on namespace and issues warnings for things as
> it overwrites things that have not been explicitly imported seems an
> unfriendly default for a CORE module, no?

Possibly, but this behaviour has existed for the past 18.5 years. It's not
going to change now.

I am going to mark this bug as rejected.

Nicholas Clark

[Lukas Mai]

On 12.05.2013 19:10, Linda Walsh via RT wrote:
> On Sat May 11 23:17:18 2013, plok...@gmail.com wrote:
>> No, that's normal. You're loading two modules, each of which redefines
>> main::getcwd().
> ---
> The idea that that the POSIX module would blindly redefine common
> functions is entirely a short-coming in the POSIX module.

No, that's the entire reason POSIX (and modules in general exist): to
define common functions.

>>> Second -- is it's not easy to shut them off.
>>
>> It's trivial to shut them off: Just remove -w.
>> There is no reason to use -w in any perl that supports 'use warnings'
>> (i.e. 5.6 or better).
> ----
> It turns out that putting the CWD module 2nd silences the problem
> as it doesn't have the same bug as the POSIX module. If the warning
> happened in both instances, I'd say you have a point. But the fact that
> it doesn't means that the POSIX module it redefining things that are
> already defined when it has not been asked to.

C:\>perl -we "use POSIX; use Cwd;"
Subroutine main::getcwd redefined at D:/strawberry/perl/lib/Exporter.pm
line 66.
at -e line 1.

1. Putting Cwd (not CWD) second doesn't silence the warning.
2. This is not a bug in POSIX.
3. You did in fact ask POSIX to redefine getcwd because that's what 'use
POSIX;' means.

> I usually support modules, like POSIX, exporting all of their
> needed routines, but with large export lists, it becomes even more
> important not to do so blindly, but check to see if the module is
> already defined in the user's context and only issue warnings for those
> modules that the user has specifically requested
> (as in use POSIX qw(getcwd) ).

getcwd is a subroutine, not a module.

No module I know explicitly checks whether the symbols it exports are
already defined. As I said before, if you wanted that to happen, the
appropriate place would be in Exporter.

If you want 'use POSIX qw(getcwd);' to do something different than 'use
POSIX;', that would be non-standard behavior. That is, it would require
custom code in POSIX that is more than just a wrapper around Exporter.
It would also behave differently than every other Perl module. And it
would be an incompatible change to the existing behavior/documentation.
All in all it sounds very unintuitive to me.

How would this interact with import tags?
For example, 'use POSIX qw(:assert_h);' exports 'assert' and 'NDEBUG'.
Does that count as specifically requesting assert and NDEBUG or not?

> That's a reasonable approach.
>
> Second -- I clearly stated that in most of my programs putting
> a "no warnings" before something that is emitting warnings HAS
> overridden the specification of "-w" on the interpreter line.

True but irrelevant. In this case the something that is emitting
warnings is in Exporter.pm, not in your code, and there is no 'no
warnings' in Exporter.pm.

> To go off and tell me why that doesn't work flied in the face of plenty
> of other examples.
>
> Should I report the 20-score or more cases where it does work as bugs?

I have no idea what you're talking about here.

>
>>> For one reason or another, the
>>> 'no warnings' in front of the
>>> 'use POSIX' doesn't turn them off.
>>
>> The reason is that 'use warnings'/'no warnings' is lexical, i.e. it only
>> affects code in the current block. The actual subroutine redefinition,
>> however, happens in the POSIX module (or probably in Exporter, even).
>> There's no way to influence warnings from other modules via 'use
>> warnings'/'no warnings'.
> ---
>
> See above... I'm now wondering about the majority of the cases
> where it does work... and wondering why...

What do you mean by "work"? As far as I can see, your code works as
expected (i.e. it does what it's documented to do).

> FWIW.. in my usage case, require POSIX was all that was needed,
> I didn't rely on any exported names (as I didn't know that they were
> exported let alone, that one of them conflicted with Cwd or that they
> would stomp on the namespace).

The second paragraph of 'perldoc POSIX' states: "*Everything is exported
by default* with the exception of ...".

If you want to load a module without importing anything, you can write
'use Some::Module ();'. This is explained in 'perldoc -f use'.

By "stomp on the namespace" do you mean "export symbols like every other
module"?

> The fact that it stomps on namespace and issues warnings for things as
> it overwrites things that have not been explicitly imported seems an
> unfriendly default for a CORE module, no?

This is not a fact. What you're describing is not the default behavior
of anything.

--
Lukas Mai <plok...@gmail.com>

[Linda Walsh via RT]

On Sun May 12 10:31:53 2013, nicholas wrote:
> On Sun, May 12, 2013 at 10:10:49AM -0700, Linda Walsh via RT wrote:
> > The idea that that the POSIX module would blindly redefine common
> > functions is entirely a short-coming in the POSIX module.
>
> Depends on one's idea of common. Both modules are *documented* as
> defining
> a routine with the same name, and, as it turns out, both have exported
> it
> by default since 5.000.

---
Acknowledged.

> No, it is doing exactly what you asked it to do - by default it
> exports
> everything. It happens that the two modules have conflicting exports.
> This will not be the only case of it.

---
??? I didn't quite parse that -- are you saying I should have seen
other warnings or did you mean that by default, POSIX exports .. over
500 names is likely to cause problems?

>
> > Should I report the 20-score or more cases where it does work as
> bugs?
>
> Depends if they are actually bugs. This is working as documented. That
> it's
> documented behaviour is not what you want or expect is *not* a bug.

----
Documented behavior of bad behavior doesn't mean it is desirable
behavior or that it shouldn't be improved. In the case of the ones that
work -- I wouldn't be strongly motivated to report them as problems
regardless of whether or not they were as they are doing what the user
"means", not adhering to some bad behavior and relying on it being
documented as an excuse for trying to fix a bad design.

Also, it isn't 'really' a inteface to IEEE Std 1003.1. If it was, it
would return the inode w/the name in "readdir" as POSIX specifies.

> > The fact that it stomps on namespace and issues warnings for things
> as
> > it overwrites things that have not been explicitly imported seems an
> > unfriendly default for a CORE module, no?
>
> Possibly, but this behaviour has existed for the past 18.5 years. It's
> not going to change now.

---
This is IMO, a major reason why perl usage is declining and is unlikely
to survive. It's maintainers refuse to allow adaptation to changing
conditions and standard and actively work to silence people who try to
change this status quo.

It's not that I am supporting unbridled change either -- to the
contrary, I'm seen as *conservative* on the SuSE list in not supporting
the wholesale teardown of past compatibility for the sake of mandating
exclusive use of new features. I.e. I want forward progress, but am a
strong proponent of preserving compatibility or automatic upgrades.

> I am going to mark this bug as rejected.

---
Sadly, Vim has responded with it's new feature list -- to go with python
RE's and integration with perl's votes falling behind almost 8:1. This
wasn't true 5 years ago...

Not allowing this as a request for upgrading the POSIX interface to
today's perl standards -- where exporting 500+ symbols by default would
be considered "bad practice", seems like you really want to see perl
gain the reputation as one of those dinosaur languages like Cobol...

I do not relish that future. I like perl, but I don't like how it is
ossifying.






---
via perlbug: queue: perl5 status: rejected
https://rt.perl.org:443/rt3/Ticket/Display.html?id=117969

[Aristotle Pagaltzis]

* Linda Walsh via RT <perlbug-...@perl.org> [2013-05-12 19:15]:

> On Sat May 11 23:17:18 2013, plok...@gmail.com wrote:
> >No, that's normal. You're loading two modules, each of which
> >redefines main::getcwd().
> ---
> The idea that that the POSIX module would blindly redefine common
> functions is entirely a short-coming in the POSIX module.

That’s how exporting works in Perl. POSIX is not doing anything unusual.

Skipping already-defined functions silently would be just as bad; The
only difference would be that you get the first instead of the last
exported function with the conflicted name. It would just hide the
conflict rather than fix it, and your code would still only be working
accidentally.

If it weren’t silent but gave a warning, then redefining vs skipping is
a wash – except that skipping incurs some more complexity to implement.

But if it did warn, you would still be coming here to complain about it.

So whether or not functions are blindly redefined on export makes no
difference – the fix for your problem is to make your code not ask two
different modules to export a function with the same name, irrespective
of whether you made it do that on purpose or not.

[Linda Walsh via RT]

On Sun May 12 11:02:49 2013, plok...@gmail.com wrote:
> > The fact that it stomps on namespace and issues warnings for things as
> > it overwrites things that have not been explicitly imported seems an
> > unfriendly default for a CORE module, no?
>
> This is not a fact. What you're describing is not the default behavior
of anything.

----
It is the documented behavior of the POSIX module:
Everything is exported by default ... This is an unfortunate backwards
compatibility feature.
---
It is documented as an unfortunate feature. How would improving it to
not give warnings if something has already defined those modules NOT be
an improvement? In what possible circumstance could it break any
existing application?

It would be completely backwards compatible, yet you and others prefer a
20-y.o. interface that is documented, rather harshly for perl standards,
as being 'unfortunate'?

Note: I confirmed your statement about the simple case for
putting "use CWD" after use POSIX", and cannot reproduce a test case
validating my initial claim... though, that said, I would be unlikely to
fabricate such a claim had I not observed it while investigating this
issue.

However, I note that I was likely confused. Of the 61 places where grep
shows me using "use POSIX", it is *always* followed by a qw(xxx), so I
never experienced the default case... which I think could still be fixed
to not be as intrusive if there was any willingness to allow an updates
or contributions addressing the problem.










---
via perlbug: queue: perl5 status: rejected
https://rt.perl.org:443/rt3/Ticket/Display.html?id=117969

[Lukas Mai]

On 12.05.2013 20:52, Linda Walsh via RT wrote:
> On Sun May 12 11:02:49 2013, plok...@gmail.com wrote:
>>> The fact that it stomps on namespace and issues warnings for things as
>>> it overwrites things that have not been explicitly imported seems an
>>> unfriendly default for a CORE module, no?
>>
>> This is not a fact. What you're describing is not the default behavior
> of anything.
> ----
> It is the documented behavior of the POSIX module:
> Everything is exported by default ... This is an unfortunate backwards
> compatibility feature.

Stop. Neither this bug nor your paragraph I quoted above are about POSIX
exporting everything by default. The bug and the paragraph are about
POSIX issuing warnings (allegedly).

> ---
> It is documented as an unfortunate feature. How would improving it to
> not give warnings if something has already defined those modules NOT be
> an improvement? In what possible circumstance could it break any
> existing application?

... and now you're back to talking about warnings. Warnings that - I
repeat - are not the default and only happen with -w. What exactly is
your proposed change?

> It would be completely backwards compatible, yet you and others prefer a
> 20-y.o. interface that is documented, rather harshly for perl standards,
> as being 'unfortunate'?

I have no idea what you're talking about here.

> Note: I confirmed your statement about the simple case for
> putting "use CWD" after use POSIX", and cannot reproduce a test case
> validating my initial claim... though, that said, I would be unlikely to
> fabricate such a claim had I not observed it while investigating this
> issue.
>
> However, I note that I was likely confused.

youdontsay.jpg

> Of the 61 places where grep
> shows me using "use POSIX", it is *always* followed by a qw(xxx), so I
> never experienced the default case... which I think could still be fixed
> to not be as intrusive if there was any willingness to allow an updates
> or contributions addressing the problem.

1. What exactly do you think is the problem?
2. What do you propose should be changed?

--
Lukas Mai <plok...@gmail.com>

[Eric Brine]

On Sun, May 12, 2013 at 1:10 PM, Linda Walsh via RT <perlbug-...@perl.org> wrote:

     It turns out that putting the CWD module 2nd silences the problem
as it doesn't have the same bug as the POSIX module.

First, that's not true for me (see below), but more importantly, you have it completely backwards. Warning about your error is not a bug. Not warning you about your error is a bug.



>perl -we"use POSIX; use Cwd qw( getcwd );"
Subroutine main::getcwd redefined at C:/Progs/perl5162-ap1602/lib/Exporter.pm line 66.
 at -e line 1.

>perl -we"use Cwd qw( getcwd ); use POSIX;"
Subroutine main::getcwd redefined at -e line 1.

[Eric Brine]

On Sun, May 12, 2013 at 2:52 PM, Linda Walsh via RT <perlbug-...@perl.org> wrote:

How would improving it to
not give warnings if something has already defined those modules NOT be
an improvement?

Easy. Importing foo() from one module yet have foo() silently calling another module's foo() is NOT an improvement. This is exactly what warnings are for.

[David Golden]

On Sun, May 12, 2013 at 2:52 PM, Linda Walsh via RT
<perlbug-...@perl.org> wrote:

> In what possible circumstance could it break any
> existing application?

The warning exists because two functions of the same name might have
very different behaviors. Cwd and POSIX have 'getcwd' that do
(approximately) the same thing, but they aren't actually exact
substitutes.

While it might be possible for, say, POSIX to determine that the
'getcwd' in the caller's namespace is actually Cwd::getcwd, there's no
way for it to know whether the user actually wanted the actual POSIX
getcwd or else Cwd's "POSIX getcwd or reimplementation of it".

So it exports, and Perl warns and the user can decide what to do about it.

I think it would surprise people for a module to not export something
it historically exported because a similarly named function were
already present, so I wouldn't go with that approach.

I would have no problem at all with having POSIX deprecate it's
@EXPORT and use @EXPORT_OK instead and warn if import is called
without arguments, (e.g. deprecate and warn in 5.20, and actually
remove @EXPORT in 5.22) but I think the odds of that being welcome by
p5p are slim at best.

That's the Perl philosophy of bending over backwards to avoid breaking old code.

I happen to disagree with that philosophy in many cases, but I seem to
regularly be in the minority.

[Konovalov, Vadim (Vadim)** CTR **]

> From: Aristotle Pagaltzis
....

> Skipping already-defined functions silently would be just as bad;

my intuition tells me this would be not "...as bad", rather this will
be much worse

[Dr.Ruud]

On 12/05/2013 03:02, Linda Walsh wrote:

> I was trying to "use POSIX" and got multiple warnings in my
> program:

> [...]

> Subroutine main::getcwd redefined at /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/POSIX.pm line 30.

Start with replacing your "use POSIX;" by "use POSIX ();".

--
Ruud

[Linda Walsh via RT]

First, I must note, this is hardly the most important issue on
my plate. I'm responding to these as mostly academic discussion,
as my program has already dealt with the issue -- and as mentioned
earlier, I'd previously only used "use POSIX" with a parameter.

On Sun May 12 18:01:14 2013, ike...@adaelis.com wrote:
> On Sun, May 12, 2013 at 2:52 PM, Linda Walsh via RT <
> perlbug-...@perl.org> wrote:
>

> > How would improving it to
> > not give warnings if something has already defined those modules NOT be
> > an improvement?
>
> Easy. Importing foo() from one module yet have foo() silently calling
> another module's foo() is NOT an improvement. This is exactly what
warnings
> are for.

----
If you import POSIX() you will get no imports.
I don't know if you mean to be this was specifically about the POSIX
module, not modules in general.

The POSIX module exports over 550 symbols, *by default*.

If something is going to export that many symbols by default,
it would seem care should be taken not to overwrite the names if
they are already in use. If warnings are issued, it would be
more appropriate (in the *default* case on this module), to
put the errors in $@ and developers who were concerned that
they got the right module from POSIX, could check $@.

It wouldn't break existing code that runs now without warnings,
so wouldn't that be enough so satisfy a reasonable person's
definition of "compatibility"?

---------------

On Sun May 12 18:32:44 2013, x...@xdg.me wrote:
> I would have no problem at all with having POSIX deprecate it's
> @EXPORT and use @EXPORT_OK instead and warn if import is called
> without arguments, (e.g. deprecate and warn in 5.20, and actually
> remove @EXPORT in 5.22) but I think the odds of that being welcome by
> p5p are slim at best.

---
But that still doesn't make it useful in the default case.

I also wish some other modules (ex. Errno) had a (:all) option, so I
wrote for myself "Errno_h" that does. People are used to the errno.h
include file including all the definitions of E_NOBLAH and
ENOTHIS or ENOTHAT, but to expect all possible POSIX calls to be
defined -- Does anyone have such a list in there head, and know what
they would be getting in advance?

It's unweildy and seems to be a not-very-useful implementation the
way it is as it already, **without warnings about specifics**,
any POSIX call that had a name collision with perl's key words.
I.e. -- it is already the case that for many posix keywords,
it doesn't warn you that they conflict with perl keywords -- you
just silently get the perl version -- right?

So, why not make that they default with all it's symbols, but
only in the default case. That way, it's behavior could
be made more consistent. Functions specified to be included would
still give warnings as they do now. But someone includes
POSIX with no specifications/parameters, then it could lower its
demands on how it communicates warnings.

Just seems like that would make it more useful in the default case,
rather than eliminating the default case altogether.

It also would make the default case easier to use:

1) If someone wants to see warnings, they can make sure POSIX is
included 1st, and any following modules will issues warnings.

However,

2) In cases where POSIX is included down in some sub-block of code,
it would be unlikely to come first in defining functions, and
it would be "upgraded in intelligence", to auto-configure what
modules it exports based on what isn't defined. Thus it not only
doesn't conflict with perl's "system namespace" but also not with
perl's general namespace for things that are already defined.

> That's the Perl philosophy of bending over backwards to avoid breaking
> old code.

---
I think the above accomplishes that.

> I happen to disagree with that philosophy in many cases, but I seem to
> regularly be in the minority.

---
Ditto.


-----
On Sun May 12 22:54:38 2013, vadim.k...@alcatel-lucent.com wrote:
> > From: Aristotle Pagaltzis

> > Skipping already-defined functions silently would be just as bad;
>
> my intuition tells me this would be not "...as bad", rather this will
> be much worse

---

Do you think that would be the case with old code? I.e. If it is
in production and runs now without warnings, would a new version
that silenced such warnings (for $warn () {...}).

Mon May 13 00:49:23 2013, rvtol+...@isolution.nl wrote:
> On 12/05/2013 03:02, Linda Walsh wrote:
> > I was trying to "use POSIX" and got multiple warnings in my
> > program:
>

> Start with replacing your "use POSIX;" by "use POSIX ();".

---

Actually I started with a "require" and changed it back after
seeing the mess "use" caused. "oops" ;-)

[Eric Brine]

On Mon, May 13, 2013 at 9:40 PM, Linda Walsh via RT <perlbug...@perl.org> wrote:

If something is going to export that many symbols by default,
it would seem care should be taken not to overwrite the names if
they are already in use.  If warnings are issued, it would be
more appropriate (in the *default* case on this module), to
put the errors in $@ and developers who were concerned that
they got the right module from POSIX, could check $@.

Expecting people to replace all isntance of

use Module;

with

BEGIN { require Module; warn $@ if $@; }

is ludicrous, not "more appropriate".