pidl s4::NDR::Parser: correct has_fast_array logic

Here we fix two bugs that cancelled each other out completely, so this
patch leaves us with exactly the same functionally as before.

Bug 1: In perl, return is *syntactically* a function.

That means 'return X or Y' is read as 'return(X) or Y', as in the
'open(X) or die "..."' construct -- Y is only evaluated if return
returns false. But return never returns, so Y is dead code. If in
doubt, try these:

perl -e "sub x {return 0 or die;} x"
perl -e "sub x {return (0 or die);} x"

What we *meant* here is 'return (X or Y)', BUT it turns out we were
confused -- the Y case was bogus.

Bug 2: string arrays never had "fast array logic" in the first place.

The fast array logic is for arrays of bytes, and can be fast (i.e.
memcpy) because there is no endianness to worry about. A string array
is an array of pointers not bytes.

Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>

1 files changed, 2 insertions, 2 deletions

diff --git a/pidl/lib/Parse/Pidl/Samba4/NDR/Parser.pm b/pidl/lib/Parse/Pidl/Samba4/NDR/Parser.pm
index 276588351a2..0ea7a683d95 100644
--- a/pidl/lib/Parse/Pidl/Samba4/NDR/Parser.pm
+++ b/pidl/lib/Parse/Pidl/Samba4/NDR/Parser.pm
@@ -84,8 +84,8 @@ sub has_fast_array($$)
 
 	my $t = getType($nl->{DATA_TYPE});
 
-	# Only uint8 and string have fast array functions at the moment
-	return ($t->{NAME} eq "uint8") or ($t->{NAME} eq "string");
+	# Only uint8 has a fast array function at the moment
+	return ($t->{NAME} eq "uint8");
 }