Ayuda con recojer una variable y preguntar si trae datos o esta vacia

[nicolaspar]

Iniciado por Neuron_376

Ya nos estamos poniendo de acuerdo...

Yo no sabia que con && evitabas el problema del compilador, tu dices que esto pasa entonces

if (!isset($_GET["cantidad_child"]) --> False ... el compilador se sale porque tienes el && y NO SE EJECUTA LA SEGUNDA LINEA

?????

Ahi es donde aun me queda la duda, de hecho yo pensaba que el && era exactamente lo mismo que and, y de hecho me parece que && realmente fuerza a ejecutar la segunda sentencia, no recuerdo porque, pero me parece que asi es, que con el && fuerzas a ejecutar ambas para evaluarlas porque las estas asociando para obtener resultado, mientras que and va evaluando 1 por 1 porque no tiene propiedad asociativa, eso es lo que recuerdo mas o menos. Pero igual, creo que con ambas la linea se ejecuta completa.

Solo que asi:

&& --> (sentencia1 && sentencia2)
and -> sentencia1 and sentencia2

Es decir, primero 1 y luego la otra, un ejemplo que encontre de esto ahorita:

$a && $b || $c -----> (a [y] b) or c
$a AND $b || $c ----> a [y] (b or c)

Lo investigue ahorita para no escribir mentiras de esto, pero igual aun pienso que se ejecuta la linea completa, aunque si no fuera asi, tendria que ser con AND y no con &&, porque && si esta forzando a realizar las dos sentencias, mientas que AND no, y asi con AND el compilador podria decir...

a = False ---> Sigue un AND ? Si si sigue un AND, entonces el resultado es False porque ya se que lo primero es falso.

En cambio con el && nunca podria hacer esa distincion porque por la propiedad de asociacion del && esta obligado a ejecutar las sentencias completas.

Creeme lo he investigado, hace unos meses se me vino la duda. Sino, probalo y veras, no es tan tremendo hacer un archivoto php y testear lo expuesto

Iniciado por Neuron_376

Lo que menciona del $_GET, bien, no puedes mandar datos con basura, pero si lo pasas como URLENCODE entonces podras mandar cadenas sucias como "__valor" "_[TAB]" etc, y esa linea que tienes no funcionara, el Isset dira true y el Empty dira False, lo que hace que pueda continuar adelante, en cambio de trim si te limpia de espacios a los lados, y de caracteres raros, por lo tanto deja una cadena vacia totalmente correcta como:

trim("_") = ""
trim("_[TAB]") = ""
trim("cadena__") = "cadena"

Entonces si sirve de mucho el trim, del SQLInjection tienes razon, faltan mas validaciones, pero este proceso es solo la primera parte, como dije, el sieguiente paso es convertir y verificar el TIPO de dato que debe ser esa variables, etc... pero eso es mas adelante.

Poco a poco sacamos los detalles no crees...

Las cosas se aclaran, pero te repito, si es de espacios, no es necesario para lo que yo expuse.
Si hablas del trim con sql injection no te saca ningun codigo maligno.
No digo con esto que sea una función que no sirva para nada, sino que en este caso no esta justificada.