[BUG null conditionals should not be allowed] #879

p5pRT · 1999-11-19T13:17:10Z

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

Searchable as RT1811$

p5pRT · 1999-11-19T13:17:10Z

From @schwern

1) Everything else (until, if, unless...) is a syntax error with an
empty condition.
2) The empty condition of a while loop is TRUE! If anything I would
expect false.
3) There's no warning.

At minimum there should be a warning, at best it should be made a
syntax error.

Here's another intersting problem:

do { print "TRUE"; sleep 1 } while ();
This produces one iteration of TRUE.

do { print "TRUE"; sleep 1 } until ();
This produces an infinite loop.

Again, the oddness:
1) Unlike with while () {...}, the null condition is false!
2) Again, no warning.

IMHO do {...} while () and do {...} until () should both be syntax
errors, or at least warnings.

Unless there's a backwards compatibility issue, all instances of an
empty conditional should probably be a syntax error. I can't think of
any time when it would be useful.

If I'm feeling brave I'll submit a patch.

PS This problem occurs under 5.005_03 and 5.005_62

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.7, archname=i686-linux
uname='linux athens 2.2.7 #2 smp mon may 10 23:17:01 edt 1999 i686 unknown '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='gcc', optimize='-O6', gccversion=egcs-2.91.66 19990314 (egcs-1.1.2 release)
cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=y, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl):
Built under linux
Compiled at Jul 29 1999 00:29:00
%ENV:
PERL5LIB="/home/schwern/lib/perl5/site_perl/5.005:/web/sites/test/mp"
@INC:
/home/schwern/lib/perl5/site_perl/5.005/i686-linux
/home/schwern/lib/perl5/site_perl/5.005
/web/sites/test/mp
/usr/lib/perl5/i686-linux
/usr/lib/perl5
/usr/lib/perl5/site_perl/5.005/i686-linux
/usr/lib/perl5/site_perl/5.005
.

Summary of my perl5 (revision 5.0 version 5 subversion 62) configuration:
Platform:
osname=linux, osvers=2.2.10, archname=i686-linux
uname='linux athens 2.2.10 #3 smp mon aug 2 16:48:09 edt 1999 i686 unknown '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
use64bits=undef usemultiplicity=undef
Compiler:
cc='cc', optimize='-g', gccversion=2.95.2 19990906 (prerelease)
cppflags='-Dbool=char -DHAS_BOOL -DDEBUGGING -I/usr/local/include -DDEBUGGING_OPS -DDEBUGGING_MSTATS -fno-strict-aliasing'
ccflags ='-Dbool=char -DHAS_BOOL -DDEBUGGING -I/usr/local/include -DDEBUGGING_OPS -DDEBUGGING_MSTATS -fno-strict-aliasing'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=y, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=/lib/libc-2.1.2.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING
Built under linux
Compiled at Oct 16 1999 16:16:24
%ENV:
PERL5LIB="/home/schwern/lib/perl5/site_perl/5.005:/web/sites/test/mp"
@INC:
/home/schwern/lib/perl5/site_perl/5.005/i686-linux
/home/schwern/lib/perl5/site_perl/5.005
/web/sites/test/mp
/usr/local/perl5.005_62/lib/5.00562/i686-linux
/usr/local/perl5.005_62/lib/5.00562
/usr/local/perl5.005_62/lib/site_perl/5.00562/i686-linux
/usr/local/perl5.005_62/lib/site_perl
.

--

Michael G Schwern schwern@pobox.com
http://www.pobox.com/~schwern
/(?:(?:(1)[.-]?)?$?(\d{3})$?[.-]?)?(\d{3})[.-]?(\d{4})(x\d+)?/i

p5pRT · 1999-11-19T13:20:20Z

From @mjdominus

For some reason, Perl accepts a while loop with an empty conditional.
while ( ) { print "TRUE"; sleep 1; }
results in a big list of TRUEs. This is odd in several ways:
1\)  Everything else $until\, if\, unless\.\.\.$ is a syntax error with an
    empty condition\.

It's legal in a `for (;;)' loop. I guess that that is the reason.

2\)  The empty condition of a while loop is TRUE\!  If anything I would
    expect false\.

Maybe because you're not thinking of for(;;)?

Unless there's a backwards compatibility issue, all instances of an
empty conditional should probably be a syntax error. I can't think of
any time when it would be useful.
If I'm feeling brave I'll submit a patch.

Make sure you don't break for(;;).

p5pRT · 1999-11-19T13:45:25Z

From @TimToady

Mark-Jason Dominus writes:
: > For some reason, Perl accepts a while loop with an empty conditional.
: > while ( ) { print "TRUE"; sleep 1; }
: > results in a big list of TRUEs. This is odd in several ways:
: >
: > 1) Everything else (until, if, unless...) is a syntax error with an
: > empty condition.
:
: It's legal in a `for (;;)' loop. I guess that that is the reason.

Yes, that was the reason.

Larry

p5pRT · 1999-11-19T13:46:23Z

From [Unknown Contact. See original ticket]

: It's legal in a `for (;;)' loop. I guess that that is the reason.

Yes, that was the reason.

What was the reason for

if BLOCK BLOCK

--tom

p5pRT · 1999-11-19T13:48:11Z

From @andk

On Fri, 19 Nov 1999 16:21:05 -0500, Mark-Jason Dominus <mjd@plover.com> said:

2) The empty condition of a while loop is TRUE! If anything I would
expect false.

Maybe because you're not thinking of for(;;)?

print "It always has been that way" while ();

Oops. Well, "it always has been that way" is true for while(){}, the
other one needs a Real True in there:

print "It always has been that way" while (1); # works

I guess, the reason for that difference would be: Programmers like
endless loops, they are a pleasure to deal with. Leave them with
last(). That's why

while (){
}

is kept for the time being. But for the

.... while ...;

construct there is no arguing because there is no last() that would
help us out. I'm only guessing.

--
andreas

p5pRT · 1999-11-19T13:59:55Z

From @TimToady

Tom Christiansen writes:
: >: It's legal in a `for (;;)' loop. I guess that that is the reason.
:
: >Yes, that was the reason.
:
: What was the reason for
:
: if BLOCK BLOCK

Premature senility. Postmature infantilism. Experimental error. Brain fart.

There's a lesson here. Generalizations are generally useless unless used.

Larry

p5pRT · 1999-11-19T14:03:24Z

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 04:17:04PM -0500, Michael G Schwern wrote:

For some reason, Perl accepts a while loop with an empty conditional.
while ( ) { print "TRUE"; sleep 1; }
results in a big list of TRUEs. This is odd in several ways:
1\)  Everything else $until\, if\, unless\.\.\.$ is a syntax error with an
    empty condition\.
2\)  The empty condition of a while loop is TRUE\!  If anything I would
    expect false\.
3\)    There's no warning\.
At minimum there should be a warning, at best it should be made a
syntax error.

While checking this out, I found a problem with B::Deparse:

% perl -MO=Deparse -e 'while () { print }'
-e syntax OK
Can't locate object method "ppaddr" via package "B::NULL" at /usr/local/lib/perl5/5.00503/i686-linux-thread/B/Deparse.pm line 325.
END failed--cleanup aborted.
% perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.0.34, archname=i686-linux-thread
uname='linux gil 2.0.34 #2 thu jul 9 10:57:48 est 1998 i686 unknown '
hint=recommended, useposix=true, d_sigaction=define
usethreads=define useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O9', gccversion=egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)
cppflags='-D_REENTRANT -Dbool=char -DHAS_BOOL -I/usr/local/include'
ccflags ='-D_REENTRANT -Dbool=char -DHAS_BOOL -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lpthread -lc -lposix -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl):
Built under linux
Compiled at Apr 15 1999 18:03:43
%ENV:
PERL_MAILERS="mail:/no/such/thing"
@INC:
/usr/local/lib/perl5/5.00503/i686-linux-thread
/usr/local/lib/perl5/5.00503
/usr/local/lib/perl5/site_perl/5.005/i686-linux-thread
/usr/local/lib/perl5/site_perl/5.005
.

Peace,
* Kurt Starsinic (Kurt.Starsinic@isinet.com) --------- Technical Specialist *
| `The term `Internet' has the meaning given that term in |
| section 230(f)(1) of the Communications Act of 1934.' |
| -- H.R. 3028, Trademark Cyberpiracy Prevention Act |
Institute for Scientific Information http://www.isinet.com/

p5pRT · 1999-11-19T14:14:57Z

From @TimToady

Andreas J. Koenig writes:
: Oops. Well, "it always has been that way" is true for while(){}, the
: other one needs a Real True in there:
:
: print "It always has been that way" while (1); # works
:
: I guess, the reason for that difference would be: Programmers like
: endless loops, they are a pleasure to deal with. Leave them with
: last(). That's why
:
: while (){
: }
:
: is kept for the time being. But for the
:
: .... while ...;
:
: construct there is no arguing because there is no last() that would
: help us out. I'm only guessing.

I think it has more to do with the fact that the statement has mandatory
parens while the modifier doesn't. Hence,

print while;

just looks kinda strange. Whereas while(){} is more like for(;;){}.
It'd be more confusing if you could write while{} without the parens.
Especially back when "while BLOCK BLOCK" still worked.

Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.

Larry

p5pRT · 1999-11-19T14:31:12Z

From [Unknown Contact. See original ticket]

Mark-Jason Dominus writes:

2\)  The empty condition of a while loop is TRUE\!  If anything I would
    expect false\.
Maybe because you're not thinking of for(;;)?

Frankly speaking, if I see `while' I prefer thinking about 'while',
not about 'for'. What about detecting in the parser, before it
becomes undistinguishable from `for'?

Ilya

p5pRT · 1999-11-19T16:03:28Z

From @TimToady

Ilya Zakharevich writes:
: Mark-Jason Dominus writes:
: > > 2) The empty condition of a while loop is TRUE! If anything I would
: > > expect false.
: >
: > Maybe because you're not thinking of for(;;)?
:
: Frankly speaking, if I see `while' I prefer thinking about 'while',
: not about 'for'. What about detecting in the parser, before it
: becomes undistinguishable from `for'?

Eh? It was explicitly coded into parser on purpose. It wasn't an
accident. Look for texpr/mtexpr in perly.y.

In fact, if you go back to the Perl 1 source code, you'll see that
there's already a texpr in the WHILE production. There wasn't an
mtexpr yet, of course, for reasons that will be obvious upon inspection...

It's just another one of those early generalizations that never quite
got into common use. Ah, well. Live and let learn.

Larry

p5pRT · 1999-11-19T16:05:28Z

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 03:56:32PM -0800, Larry Wall wrote:

: Frankly speaking, if I see `while' I prefer thinking about 'while',
: not about 'for'. What about detecting in the parser, before it
: becomes undistinguishable from `for'?

Eh? It was explicitly coded into parser on purpose. It wasn't an
accident. Look for texpr/mtexpr in perly.y.

In fact, if you go back to the Perl 1 source code, you'll see that
there's already a texpr in the WHILE production. There wasn't an
mtexpr yet, of course, for reasons that will be obvious upon inspection...

It's just another one of those early generalizations that never quite
got into common use. Ah, well. Live and let learn.

Should not it go the same as the other one:

perl -wle 'if {1} {print 12}'
syntax error at -e line 1, near "if {"
Execution of -e aborted due to compilation errors.

Ilya

p5pRT · 1999-11-19T16:09:55Z

From @TimToady

Ilya Zakharevich writes:
: On Fri, Nov 19, 1999 at 03:56:32PM -0800, Larry Wall wrote:
: > It's just another one of those early generalizations that never quite
: > got into common use. Ah, well. Live and let learn.
:
: Should not it go the same as the other one:
:
: perl -wle 'if {1} {print 12}'
: syntax error at -e line 1, near "if {"
: Execution of -e aborted due to compilation errors.

Why? I didn't say live and learn, I said live and let learn. :-)

Larry

p5pRT · 1999-11-19T16:11:58Z

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 04:09:33PM -0800, Larry Wall wrote:

: Should not it go the same as the other one:
:
: perl -wle 'if {1} {print 12}'
: syntax error at -e line 1, near "if {"
: Execution of -e aborted due to compilation errors.

Why? I didn't say live and learn, I said live and let learn. :-)

The same because as for if {1} {print 12}?

Ilya

p5pRT · 1999-11-19T16:34:48Z

From @TimToady

Ilya Zakharevich writes:
: On Fri, Nov 19, 1999 at 04:09:33PM -0800, Larry Wall wrote:
: > : Should not it go the same as the other one:
: > :
: > : perl -wle 'if {1} {print 12}'
: > : syntax error at -e line 1, near "if {"
: > : Execution of -e aborted due to compilation errors.
: >
: > Why? I didn't say live and learn, I said live and let learn. :-)
:
: The same because as for if {1} {print 12}?

There was no because. We broke "if {1}" totally by accident, and only
left it broken because nobody had complained in the intervening
months. Unless you can think of something else that "while ()" ought
to mean, I think we should leave it as it is.

Larry

p5pRT · 1999-11-19T16:41:45Z

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 04:31:31PM -0800, Larry Wall wrote:

: The same because as for if {1} {print 12}?

There was no because. We broke "if {1}" totally by accident, and only
left it broken because nobody had complained in the intervening
months. Unless you can think of something else that "while ()" ought
to mean...

Misprint? ;-)

Ilya

p5pRT · 1999-11-19T20:36:33Z

From @vanstyn

In <sfc7ljekva5.fsf@hohenstaufen.in-berlin.de>, Andreas J. Koenig writes:
:>>>>> On Fri, 19 Nov 1999 16:21:05 -0500, Mark-Jason Dominus <mjd@plover.com>
:said:
:
:>> 2) The empty condition of a while loop is TRUE! If anything I would
:>> expect false.
:
: > Maybe because you're not thinking of for(;;)?
:
: print "It always has been that way" while ();
:
:Oops. Well, "it always has been that way" is true for while(){}, the
:other one needs a Real True in there:
:
: print "It always has been that way" while (1); # works

I think this is more likely due to the fact that in the modifier form,
the '()' is treated as an empty list; this cannot happen in the
statement form.

Hugo

p5pRT closed this as completed Nov 28, 2003

p5pRT added Severity Medium distro-Linux documentation labels Oct 18, 2019

p5pRT mentioned this issue Oct 19, 2019

Program terminated with signal 11, Segmentation fault. #12469

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG null conditionals should not be allowed] #879

[BUG null conditionals should not be allowed] #879

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

[BUG null conditionals should not be allowed] #879

[BUG null conditionals should not be allowed] #879

Comments

p5pRT commented Nov 19, 1999

p5pRT commented Nov 19, 1999

From @schwern

p5pRT commented Nov 19, 1999

From @mjdominus

p5pRT commented Nov 19, 1999

From @TimToady

p5pRT commented Nov 19, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Nov 19, 1999

From @andk

p5pRT commented Nov 19, 1999

From @TimToady

p5pRT commented Nov 19, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Nov 19, 1999

From @TimToady

p5pRT commented Nov 19, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Nov 19, 1999

From @TimToady

p5pRT commented Nov 19, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Nov 19, 1999

From @TimToady

p5pRT commented Nov 19, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Nov 19, 1999

From @TimToady

p5pRT commented Nov 19, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Nov 19, 1999

From @vanstyn