CGI syntax error not behaving as I expected but...

[mmosher]

.... doing exactly what its supposed to do.

I wrote a perl script to allow me to look at portions of the log that is
kept for people searching. It was written some time ago and seemed to
work perfectly. It was not until last week that I noticed that after
12pm the time would jump back an hour and stay that way until 12am. I
suspected a bug but doubled check incase of some weird virus or something.

Of course it was a bug:

if (substr($date_time_raw[$loop],8,2)<12) {##do something}
elsif (substr($date_time_raw[$loop],8,2)=12) {##do something}

else
{##do something}

Of course the error is in the elsif statement it should be ==12 not =12.
So of course it works in the am the pm messes up.

My question is this: I thought a syntax error of this type would not run
and that I would get an error with no output? Or is this type of error
considered a warning?

I am fairly inexperienced in perl and usually have to write stuff as "we
need this up tommorrow. Figure it out quick" kinda of situation which is
not a good way to actually learn and understand. I also do most of perl
work in the morning and it did not occur to change the clock and test
different hours. Lesson learned.

Thank you.

 

[Ben Morrow]

Of course it was a bug:

if (substr($date_time_raw[$loop],8,2)<12) {##do something}
elsif (substr($date_time_raw[$loop],8,2)=12) {##do something}

else
{##do something}

My question is this: I thought a syntax error of this type would not run
and that I would get an error with no output? Or is this type of error
considered a warning?

Using substr as an lvalue like this is perfectly valid Perl. Read
perldoc -f substr again.

perl -le'my $x = "abc"; substr($x, 1, 1) = "XXX"; print $x'

Ben

 

[Paul Lalli]

Of course it was a bug:

if (substr($date_time_raw[$loop],8,2)<12) {##do something}
elsif (substr($date_time_raw[$loop],8,2)=12) {##do something}

else
{##do something}

Of course the error is in the elsif statement it should be ==12 not =12.
So of course it works in the am the pm messes up.

My question is this: I thought a syntax error of this type would not run
and that I would get an error with no output? Or is this type of error
considered a warning?

That's not a syntax error. Assigning a value to a substring is a
perfectly legal operation. It's just not what you wanted to do. That
line says "find the 2 character substring from the variable
$date_time_raw[$loop] starting at position 8, and replace it with the
string "12". There's no syntax error there at all.

Paul Lalli

 

[Glenn Jackman]

elsif (substr($date_time_raw[$loop],8,2)=12) {##do something}

My question is this: I thought a syntax error of this type would not run
and that I would get an error with no output? Or is this type of error
considered a warning?

Using substr as an lvalue like this is perfectly valid Perl. Read
perldoc -f substr again.

This is precisely why you might see some (particularly C code) written
like:
if (1 == someVar) {...}
because the typo
if (1 = someVar) {...}
_would_ trigger an error.

 

[mmosher]

Thank you both for the explaination. Should have relized with was my
logic error and not syntax. My thinking was that since it was in an if
statement I could not do an assignment. Everything makes sense now. I'll
check that document.

Yes I can be taught.

 

[Thomas Kratz]

Thank you both for the explaination. Should have relized with was my
logic error and not syntax. My thinking was that since it was in an if
statement I could not do an assignment. Everything makes sense now. I'll
check that document.

Yes I can be taught.

Can you be taught to stop top posting?

Thomas

 

[mmosher]

Can you be taught to stop top posting?

Thomas

Sorry about that. Even though I don't post much I do know about that and
for some reason I didn't post correctly.

 

[Ben Morrow]

The same compiler laxity is present in C and C++, and this is a common
error there, too. I have seen programmers turn the conditional around,
putting the constant first:

if( 12 == substr($date_time_raw[$loop] ) { ## do something }

Then, if they forget the second equal sign, the compiler terminates
with a syntax error:

"Can't modify constant item in scalar assignment at myprogram.pl line
2, near ") ) "

I don't do this because I don't like the readability of the result, but
it does work.

I, OTOH, often do do this, because I much prefer list operators
without parentheses:

if (12 == substr $data_time_raw[$loop], 8, 2) { }

TMTOWTDI, as usual

Ben

 

[Uri Guttman]

JG> As pointed out by others, this is not a syntax error. However, if you
JG> had put "use warnings" at the top of your program, perl would have
JG> flagged the assignment in the if conditional as a warning:

JG> "Found = in conditional, should be == at myprogram.pl line 2."

that warning is not worded correctly. look at these:

perl -we 'if ( my $x = 3 ) {print "foo\n"}'
Found = in conditional, should be == at -e line 1.
foo

perl -we 'if ( my $x = $y ) {print "foo\n"}'
Name "main::y" used only once: possible typo at -e line 1.

perl -we 'if ( $x = $y ) {print "foo\n"}'
Name "main::x" used only once: possible typo at -e line 1.
Name "main::y" used only once: possible typo at -e line 1.

that warning only happens when you assign a constant in the
conditional. i use if ( my $x = $y ) in plenty of places. $y is really
most commonly a hash lookup like this:

if ( my $foo = $self->{'foo'} ) {

do something with $foo
}

this keeps $foo tightly scoped. it also eliminates the extra hash lookup
that would be needed otherwise. the typical ways that is coded is:


if ( $self->{'foo'} ) {

do something with $self->{'foo'}
}

or

my $foo = $self->{'foo'} ;
if ( $foo ) {

do something with $foo
}

JG> The same compiler laxity is present in C and C++, and this is a common
JG> error there, too. I have seen programmers turn the conditional around,
JG> putting the constant first:

JG> if( 12 == substr($date_time_raw[$loop] ) { ## do something }

and another point i should mention to the OP, substr deal with strings
so the == should be eq. and if it was that, then the confusion over = vs
== wouldn't happen.

this constant on the left trick is old and the book code complete
mentions it. since i don't fall into the =/== bugs (too) often, i don't
worry about it.

JG> I don't do this because I don't like the readability of the result, but
JG> it does work.

same here.

uri

 

[Michele Dondi]

Can you be taught to stop top posting?

Also, it is customary that people post here (OT) CGI questions wrongly
assuming that CGI==Perl, without even specifying in the subject line
that their post is about CGI. This, along with the actual nature and
tone of those questions, tends to cause irritation in many group
regulars.

Now you have the opposite situation, where you had a true Perl
question that you presented like a CGI one: note that many valuable
contributors to this ng may have kept away from this thread because of
this and the above mentioned circumstance!

I suggest you try to choose more pertinent subjects for the future...


Michele