|
Re^4: Hash key composition with a comma? (Semipredicate problem)
by LanX (Saint) on Mar 17, 2018 at 22:19 UTC
|
It's a variation of the Semipredicate problem.
Another variation are Null-terminated strings in C. *
In other words, if you use a "special" value (here the delimiter) you have to make sure that the input (here keys) can't include them, and that's why you even have the freedom to chose the delimiter by setting $;
Such approaches happen constantly in programming and people make sure that such values are excluded, IFF they need the benefits. (For example by escaping or the choice of delimiter in q , qq or even << here-docs.)
Calling for deprecation doesn't make sense here, since one doesn't easily and accidentally stumble over this feature.
It's similar to goto , it's rarely used, doesn't cause problems, but is sometimes extremely handy to simplify an algorithm, where speed matters.
*) and yes I once got bitten by this because a badly written WMLScript interpreter couldn't distinguish between a NULL byte and the ASCII character "0". But this interpreter was buggy, there was otherwise no possibility to introduce a NULL-byte into a string. | [reply] |
Re^4: Hash key composition with a comma?
by Your Mother (Archbishop) on Mar 17, 2018 at 18:34 UTC
|
An example, AKA proof, is actually necessary when one makes an assertion in the sciences. That you bloviated instead of backing up the statement is plenty of proof for my own assertions.
| [reply] |
|
|
I second you, cause it's very hard to construct a scenario where multi dim hashes cause a bug, even if the programmer was so naive to allow random keys.
And the statement:
> If your data contains the separator-character, the code breaks.
Is not true. The constructed key would have more separator characters but wouldn't "break".
I'd really like to see a believable example, maybe I am missing something?
| [reply] |
|
|
Not sure if believable, but imagine
my $k1a = "a$;b";
my $k1b = 'c';
my $k2a = 'a';
my $k2b = "b$;c";
$multi{$k1a, $k1b} = 1;
$multi{$k2a, $k2b} = 2;
print $multi{$k1a, $k1b}; # 2!!
($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
An example, AKA proof, is actually necessary when one makes an assertion in the sciences.
Firstly, examples are not proofs "in the sciences" unless they are counterexamples.
Secondly, this is misplaced pedantry. It really is quite obvious that, when you rely on metacharacters, your data had better not inadvertently include them. This is not an assertion that needs to be proven to anybody with a modicum of programming experience. AM was entirely correct on that point.
I'll agree that AM's admonition against using the feature was hyperbolic. Sometimes it is better to avoid the pitfalls of some language feature than it is to avoid the feature itself. And we are entirely capable of doing so. (As Rolf points out.)
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
> Firstly, examples are not proofs "in the sciences" unless they are counterexamples
Yeah, but effectively that's what Your Mother was asking for, a counterexample for the thesis that multidimensional hashes are safe.
Hence a "proof" according to you. ;)
update
to elaborate more: every example proofs something, but not every proof needs an example.
Or in formal notation:
Example => Proof
So of course YM's "aka" is not correct in mathematics.
But in IT it's important to see how likely a problem is, because nothing is without risk.
For instance the same problem might be easily solved with multidimensional keys, where hashes of hashes have a higher risk to run out of space or to be vulnerable of bugs because of higher algorithmic complexity.
| [reply]
[d/l] |
|
|
|
|
The reason I asked is because it's sundialsvc4 posting anonymously and inexpertly again. He absolutely could not demonstrate what you suggest. That's the point of asking him. One does not get to say, this is trivial and then substitute handwaving for technical details. An anonymous-hat-monk called me out once when I said something was semi-trivial so I backed it up because I know what I'm doing and while I'm just as in love with the sound of my keyboard as the ruler of Worst Nodes I'm also interested in helping others. This is not only a site for the competent hackers you imagine. It's also a site for beginners and knowledge seekers. Explicit examples like choroba and LanX produced serve the monastery infinitely better.
I have said many, many times SunnyD is often half right and that allows others to read into the wrong half and make assumptions or contortions or edge-cases to make it right. But half a cup of poison is still a problem and I am going to continue to slap it out of his hands when he offers it.
| [reply] |
|
|
|
|
|
|
|
|
|
