Derick,
The case we're talking about here is where a Unicode string containing
only ASCII characters is passed to an extension, not a binary string
with the same characters.
-Andrei
On May 15, 2006, at 2:53 PM, Derick Rethans wrote:
Yeah, but that doesnt mean you need to throw a hard error
On Mon, May 15, 2006 4:19 pm, Andrei Zmievski wrote:
> That assumes there are a hundred places where you want to receive an
> ASCII string. Are they really that prevalent?
How many of the extension libraries are Unicode-ready?
You see an awful lot of users with quasi-Unicode data that gets into
t
On Mon, 15 May 2006, Nuno Lopes wrote:
I was not refering to the html/xhtml/xml input. I was talking about the
charset parameter, for example. I don't want a chinese string passed as
the
charset name (the libtidy API isn't localized yet :) ). The same applies
for
the other functions.
Yeah,
On Mon, 15 May 2006, Nuno Lopes wrote:
> I was not refering to the html/xhtml/xml input. I was talking about the
> charset parameter, for example. I don't want a chinese string passed as the
> charset name (the libtidy API isn't localized yet :) ). The same applies for
> the other functions.
Yeah
I was not refering to the html/xhtml/xml input. I was talking about the
charset parameter, for example. I don't want a chinese string passed as the
charset name (the libtidy API isn't localized yet :) ). The same applies for
the other functions.
Nuno
Are you sure want to generate a hard error
Are you sure want to generate a hard error if tidy_parse_string()
doesn't get an ASCII string?
-Andrei
On May 15, 2006, at 2:30 PM, Nuno Lopes wrote:
Looking only to the tidy extension:
tidy_parse_string
tidy_parse_file
tidy_repair_string
tidy_repair_file
tidy_getopt
tidy::__constructor
tidy:
Looking only to the tidy extension:
tidy_parse_string
tidy_parse_file
tidy_repair_string
tidy_repair_file
tidy_getopt
tidy::__constructor
tidy::parseFile
tidy::parseString
I would say that others extensions will need too. Think in charset names,
options names, options values, etc..
Nuno
That
That assumes there are a hundred places where you want to receive an
ASCII string. Are they really that prevalent?
-Andrei
On May 15, 2006, at 12:42 PM, Nuno Lopes wrote:
Sorry for the delay.
But I think that a new type specifier could be introduced. If not you
are saying to extensions write
Sorry for the delay.
But I think that a new type specifier could be introduced. If not you are
saying to extensions writers to duplicate the code below a hundred times:
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "t", &name, &name_len,
&name_type) == FAILURE) {
return;
}
if (name
Check out ext/unicode/property.c where zend_unicode_to_ascii() is being
used.
-Andrei
On May 9, 2006, at 12:02 AM, Derick Rethans wrote:
On Mon, 8 May 2006, Andrei Zmievski wrote:
There is no way to do it right now. I could see it being useful,
though.
Anyone else have an opinion on this?
On Mon, 8 May 2006, Andrei Zmievski wrote:
> There is no way to do it right now. I could see it being useful, though.
> Anyone else have an opinion on this?
I think we should have a look at it when there is a real need for it as
I think it's going to be a pain for the users...
Derick
--
Deric
There is no way to do it right now. I could see it being useful,
though. Anyone else have an opinion on this?
On May 8, 2006, at 3:33 PM, Nuno Lopes wrote:
Hi,
Is there a way (planed or already implemented) to accept an ascii
string in zend_parse_parameters()?
There is the 't', but then I ha
12 matches
Mail list logo
