[BUG] Leeg attribute in tag geparsed als 0

[Daos]

Tagjes werken op twee manieren:

1. [code language=php, filename=hello.php]:
   
   PHP: hello.php
   

   echo 'Hello World!';

2. [code=php,,,hello.php]:
   
   PHP: hello.php
   

   echo 'Hello World!';

In het tweede voorbeeld is het eerste regelnummer 0 ipv 1. Deze twee voorbeeldjes zouden hetzelfde moeten zijn, want in de UBB-faq staat:

quote: http://gathering.tweakers.net/forum/faq/ubb

Attributen kunnen in deze (tweede) syntax weggelaten worden door niets tussen de komma's in te vullen: [img=,,1]

[BasieP]

tweede argument van een [code ] tag is het startende regelnummer. Waarschijnlijk is door het gebruik van de , , , constructie zo dat het tweede argument als 0 gezien wordt.

zie ook:
[code=php,0]boe[/code]

PHP:

boe

[ Voor 18% gewijzigd door BasieP op 24-04-2007 14:13 ]

[crisp]

Een lege string evalueert in PHP inderdaad naar 0 als je het cast naar int; wellicht moet de functie expliciet checken op een lege string en dan alsnog de default (1) nemen.

[Daos]

crisp schreef op woensdag 25 april 2007 @ 01:28:
expliciet checken op een lege string

Je moet alleen oppassen dat je hiervoor niet empty(..) gaat gebruiken. empty("0") geeft namelijk ook waar terug. .. == "" gaat wel goed:

PHP:

$ins = array("1", "", " ", "0");

foreach ($ins as $in)
  echo 'empty("'.$in.'") => '.(empty($in)?'true':'false').'<br>';

echo '<br>';

foreach ($ins as $in)
  echo 'trim("'.$in.'")=="" => '.(trim($in)==""?'true':'false').'<br>';

Geeft:

empty("1") => false
empty("") => true
empty(" ") => false
empty("0") => true

trim("1")=="" => false
trim("")=="" => true
trim(" ")=="" => true
trim("0")=="" => false

Als het goed is zit de trim al in de lexer/tokenizer verwerkt.

[crisp]

Daos schreef op woensdag 25 april 2007 @ 11:28:
[...]


Je moet alleen oppassen dat je hiervoor niet empty(..) gaat gebruiken. empty("0") geeft namelijk ook waar terug. .. == "" gaat wel goed:
[...]

Dat hoef je mij niet te vertellen hoor

[moto-moi]

En de parser is geschreven in c++, niet dat vieze php

[Daos]

crisp schreef op woensdag 25 april 2007 @ 11:33:
[...]

Dat hoef je mij niet te vertellen hoor

Ik heb het zelf kort geleden fout gedaan. Ik dacht ik waarschuw je maar even...

moto-moi schreef op woensdag 25 april 2007 @ 11:34:
En de parser is geschreven in c++, niet dat vieze php

In de cpp-string zit wel een normale empty(). Als je een c-string hebt, dan kan je ook kijken of het eerste karakter 0 is. Voorbeeldje (geeft "true" bij vol en "false" bij leeg):

C++:

#include <iostream>
#include <string>

typedef char* cstring;

#define count(array) \
(array && sizeof(array)? sizeof(array) / sizeof(array[0]): 0)

#define foreach(loopvar, array, statements) { \
  int _i; \
  for (_i = 0; _i < count(array); _i++) { \
    loopvar = array[_i]; \
    {statements} \
  } \
}


int main(int argc, char *argv[])
{
  cstring ins[] = {"", "0"};
  cstring in;

  foreach(in, ins,
    cout << "!string(\"" << in << "\").empty() => "
         << (!string(in).empty()?"true":"false") << endl;
  )

  cout << endl;

  foreach(in, ins,
    cout << "*\"" << in << "\" => "
         << (*in?"true":"false") << endl;
  )

  return 0;
}

En dat geeft:

!string("").empty() => false
!string("0").empty() => true

*"" => false
*"0" => true

Zolang in c++ code 4 keer zo lang is, vind ik het niet zo erg dat php een beetje vies is.

[crisp]

moto-moi schreef op woensdag 25 april 2007 @ 11:34:
En de parser is geschreven in c++, niet dat vieze php

De initialisatie van de lijnnummering wordt door React gedaan, en daar gaat het ook fout:

PHP:

if (!isset($attr['line']) || $attr['line'] < 0)
    $attr['line'] = 1;

[Daos]

crisp schreef op woensdag 25 april 2007 @ 16:15:
[...]

De initialisatie van de lijnnummering wordt door React gedaan, en daar gaat het ook fout:

PHP:

if (!isset($attr['line']) || $attr['line'] < 0)
    $attr['line'] = 1;

Kan isset($attr['line']) niet gewoon false teruggeven? Volgens mij kan je het beste zo vroeg mogelijk de 2 tag-manieren naar dezelfde constructie brengen.

[crisp]

Daos schreef op woensdag 25 april 2007 @ 16:45:
[...]

Kan isset($attr['line']) niet gewoon false teruggeven? Volgens mij kan je het beste zo vroeg mogelijk de 2 tag-manieren naar dezelfde constructie brengen.

Nee, want in andere gevallen kan een lege string wel een geldige attribuut-waarde zijn.

[Daos]

crisp schreef op woensdag 25 april 2007 @ 16:58:
[...]

Nee, want in andere gevallen kan een lege string wel een geldige attribuut-waarde zijn.

En wat is het probleem?

[tagname attribute1=value1 attribute2= attribute4=""] content [/tagname]:
attribute1 == "value1"
attribute2 == "" (of: bestaat niet)
attribute3 bestaat niet
attribute4 == ""

[tagname value1,,""] content [/tagname]:
attribute1 == "value1"
attribute2 bestaat niet
attribute3 == ""
attribute4 bestaat niet

[crisp]

Dan zou je dus verplicht quotes moeten gaan gebruiken om aan te geven dat iets een lege string is...

[BasieP]

en bij het [code] element mag ik toch aannemen dat je niet code op de 0ste regel kan hebben.

dus je zou in dat geval in ieder geval de < 0 kunnen vervangen door een < 1
Dit lost direct het empty verhaal op (bij code tags dus)

echter bij andere elementen kan ik me voorstellen dat je daar expliciet wel wilt dat iets '0' kan zijn.

als ik het zo zie lijken het dus 2 bugs die enigszinds verwand zijn

crisp schreef op woensdag 25 april 2007 @ 01:28:
Een lege string evalueert in PHP inderdaad naar 0 als je het cast naar int; wellicht moet de functie expliciet checken op een lege string en dan alsnog de default (1) nemen.

een simpele is_numeric() voordat je hem cast zou dus kunnen werken?

[ Voor 39% gewijzigd door BasieP op 25-04-2007 17:48 ]

[Daos]

crisp schreef op woensdag 25 april 2007 @ 17:42:
Dan zou je dus verplicht quotes moeten gaan gebruiken om aan te geven dat iets een lege string is...

Nee. De default kan in dat geval een lege string zijn. Of is er niet een mooi systeem voor defaults?

BasieP schreef op woensdag 25 april 2007 @ 17:45:
dus je zou in dat geval in ieder geval de < 0 kunnen vervangen door een < 1

Dat sowieso... Ik heb nog nooit een editor gezien die niet bij 1 begon.

[crisp]

Lokaal fixed in 1.9.5