Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function

[Hans Henrik Bergan]

On Fri, 3 May 2024 at 17:49, Derick Rethans  wrote:
>
> Which *API* in PHP is 1-indexed?
>
> cheers,
> Derick

Certainly isn't normal but found 1 (and only 1!):

$stmt = $pdo->prepare('SELECT name FROM users WHERE id = ?');
$stmt->bindParam(1, $id);

Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds

[Hans Henrik Bergan]

On Tue, 5 Mar 2024 at 20:17, Larry Garfield  wrote:
>
> A 3 way up-down vote doesn't make sense.  What happens if none of the 3 
> options reaches 66%?
>
> The viable options here are a single RCV vote (which we've done before), or a 
> single "Should we do this" vote that requires 66%, followed by a "when should 
> we do this" vote with 2 options, majority wins.
>
> --Larry Garfield

Does this work for you guys?

= Proposed Voting Choices =

### 1. Enhancement of Precision: Float Arguments for Sub-Second Precision

**Should we extend `sleep()` to accept floats for sub-second delays?**
- Yes
- No

**Which PHP version should implement this feature if accepted?**
- 8.4
- 9.0

### 2. Normalized Return Values on Windows

**Should we modify `sleep()` on Windows for consistent return values?**
- Yes
- No

**Which PHP version should implement this feature if accepted?**
- 8.4
- 9.0

### 3. Enhanced Return Value Precision

**Should we increase `sleep()` return value precision to include
fractions of a second?**
- Yes
- No

**Which PHP version should implement this feature if accepted?**
- 8.4
- 9.0

@Tim
>adding a short *nix explanation of when sleep will
return earlier than expected would be helpful

Where should that be? in the "Introduction" section? or the "Proposal"
section? (or elsewhere?)

Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds

[Hans Henrik Bergan]

Voting has now been simplified to 3x  no/php 8.4/php 9.0 questions.
(I actually would've preferred the original 6, would have been
unambiguous if people are supposed to checkbox only 8.4 or both 8.4
and 9.0, and would have been easier to see the % of people who voted
only 9.0, I think. But I don't care enough about it to actually fight
for it, and multiple people requested it be reduced to 3, so let's go
with that :) )

>That said, thanks for making this, it's something I'd like to see in PHP as 
>well.

Happy to hear it :)


> - Instead of using backticks, use `sleep()` for inline and
`…` for multi-line snippets. This comes with syntax
highlighting and documentation links.
>(...)
> - It would help readability if you'd use additional headlines for each
of the three sub-proposals within the Proposal section.
>

I don't want to spend too much effort on nitpicks, but if someone
volunteers to improve it, I'd be happy to add it, in which case please
send a PR to 
https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md

> For (2) it would help if you'd explain what it means for sleep() to be
interrupted and how this can happen. I believe this is signal-handling
related, but writing it out explicitly for the folks that didn't yet
encounter it would probably make sense.

I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2,
I couldn't actually get it to return 192. (nor return anything except 0):
- When sending a WM_CLOSE message (equivalent to `taskkill /IM
php.exe`), it was just completely ignored: PHP kept sleeping.
- When doing a TerminateProcess() call (equivalent to `taskkill /IM
php.exe /F`), PHP was just terminated, sleep never returned.
- When sending a CTRL_C_EVENT (equivalent to ctrl+C), PHP just
terminated, sleep never returned.
- When sending a CTRL_BREAK_EVENT (equivalent to ctrl+Break), PHP just
terminated, sleep never returned.

I don't know how to make it return 192 on Windows.. Anyone know?

>For the "Unaffected PHP Functionality" you could just spell out that anything 
>that is not the sleep() function will be unaffected

meh, someone else pointed out that the irrelevant sections could be
removed, I removed the "Unaffected PHP Functionality" section (along
with 2-3 others)

> I'd just put a single "Do all of this in the next minor" vote there. All
>of the suggested improvements make sense to me and the breaking changes
>are mostly theoretical.

meh, I don't want to risk the RFC getting rejected because too many
people thought it should be done in next.major instead of next.minor,
let's keep both next.minor + next.major vote options. (You're probably
right, I predict a majority vote for next.minor for all 3, but i'll
keep the vote options just in case.)

>I don't think I've ever seen anything using the return value of sleep().

same here.

>Don't forgot to open up a dedicated explicit discussion thread once you move 
>it into the "Discussion" phase.

How would I even do that? Linking to
https://externals.io/message/122388 isn't sufficient?

Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds

[Hans Henrik Bergan]

Made a RFC draft: https://wiki.php.net/rfc/sleep_function_float_support

First time, so I'm not surprised if there are some mistakes there.

Feedback is very welcome.


I have tried sending this email 4 times over 2 days from hans at loltek dot
net and every time the email server said delivery failed... So trying from
an alternative email address..

Re: [PHP-DEV] automatic formatting checks for pull requests?

[Hans Henrik Bergan]

i have tested running clang-format against the entire php-src
codebase, and there is only 1 file it breaks:
ext/spl/spl_directory_arginfo.h
more details at
https://github.com/php/php-src/pull/13417#issuecomment-1950920114


On Sun, 18 Feb 2024 at 01:45, Derick Rethans  wrote:
>
> On 17 February 2024 22:18:05 GMT, Ilija Tovilo  wrote:
> >Hi Hans
> >
> >On Sat, Feb 17, 2024 at 3:31 PM Gina P. Banyard  wrote:
> >>
> >> On Saturday, 17 February 2024 at 11:24, Hans Henrik Bergan 
> >>  wrote:
> >>
> >> > Can we add automatic formatting checks for pull requests?
> >> > Made a PR: https://github.com/php/php-src/pull/13417
> >>
> >> It would be nice to have some formatting rules to harmonize the codebase 
> >> as it is somewhat the wild west,
> >> but as far as my understanding goes is that Clang format struggles to 
> >> understand our codebase (namely macros) and is difficult to set-up for 
> >> php-src.
> >
> >Right. Consistent code style is nice, but what we have now is really
> >not that bad. There are a couple things I'd want if we enforce code
> >style:
> >
> >* Fixing the style should be easy, running a single command without
> >first pushing to CI.
> >* It should be fast too, so that I can easily run it for every commit,
> >preferably even on-save in my editor.
> >* The new code style should be applied only to newly added sections or
> >changed code, not entire files. Otherwise, we'll have many changes in
> >large files, with endless merge conflicts when merging up from lower
> >branches.
> >* The formatting tool should work for all php-src code, not just plain
> >C code. We don't want to be forced to refactor old macros just because
> >we need to add a single line to some long-standing code. Last time I
> >tried clang-format, it utterly failed with our macros.
> >
> >I haven't looked at your PR in detail, so I'm not sure which of these
> >points it satisfies. It would be great if you could quickly describe
> >how it works, and what the goals are.
> >
> >Essentially, I'm just sceptical that this isn't more trouble than it's worth.
> >
> >Ilija
>
> IMO, clang-format isn't really suitable. Its untunable style is often far 
> from the coding style that we currently have, and it makes some really odd 
> choices as to when and how to wrap lines, making code definitely less 
> readable.
>
> cheers
> Derick

> IMO, clang-format isn't really suitable. Its untunable style is often far 
> from the coding style that we currently have, and it makes some really odd 
> choices as to when and how to wrap lines, making code definitely less 
> readable.

it is far from "untunable", the manpage for tuning is huge:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html

Re: [PHP-DEV] automatic formatting checks for pull requests?

[Hans Henrik Bergan]

On Sun, 18 Feb 2024 at 00:51, Ilija Tovilo  wrote:
>
> Hi Hans
>
> On Sat, Feb 17, 2024 at 3:31 PM Gina P. Banyard  wrote:
> >
> > On Saturday, 17 February 2024 at 11:24, Hans Henrik Bergan 
> >  wrote:
> >
> > > Can we add automatic formatting checks for pull requests?
> > > Made a PR: https://github.com/php/php-src/pull/13417
> >
> > It would be nice to have some formatting rules to harmonize the codebase as 
> > it is somewhat the wild west,
> > but as far as my understanding goes is that Clang format struggles to 
> > understand our codebase (namely macros) and is difficult to set-up for 
> > php-src.
>
> Right. Consistent code style is nice, but what we have now is really
> not that bad. There are a couple things I'd want if we enforce code
> style:
>
> * Fixing the style should be easy, running a single command without
> first pushing to CI.
> * It should be fast too, so that I can easily run it for every commit,

Yeah..  Basically clang-format-diff (not clang-format, but clang-format-diff)
is difficult to work with, the easiest approach would be to make a
full copy of the current working dir,
and in that copy instruct git to reset to master and apply the diff
between master and the parent working dir,
and then have clang-format-diff analyze it and make its formatting suggestions,
-but- that will not be fast, that will be slow. Haven't found a fast
way to get clang-format-diff to work with a *dirty* workingdir against
master,
-yet- at least. Feel free to investigate, I'm pretty sure it can be
done, but don't know how to do it.
> preferably even on-save in my editor.

If we can make it fast, we could make some opt-in git-commit-hook to format it
(but we need to figure out the dirty-working-dir-speed thing first)

> * The new code style should be applied only to newly added sections or
> changed code, not entire files. Otherwise, we'll have many changes in
> large files, with endless merge conflicts when merging up from lower
> branches.

Yeah, that's already in place :)


> * The formatting tool should work for all php-src code, not just plain
> C code. We don't want to be forced to refactor old macros just because
> we need to add a single line to some long-standing code. Last time I
> tried clang-format, it utterly failed with our macros.

Seems to work with macros when I tested it :) Tested it with the
following macros as of writing:
ZEND_PARSE_PARAMETERS_START
Z_PARAM_NUMBER
ZEND_PARSE_PARAMETERS_END
Z_TYPE_P
Z_LVAL_P
UNEXPECTED
ZEND_ASSERT
RETURN_DOUBLE
RETURN_LONG
RETURN_THROWS


While .php and .phpt and whatever formatting can be implemented in the future,
I would prefer baby steps, once we have *.[ch] accepted, improving it
with .php/whatever
should be easier in the future.

>
> I haven't looked at your PR in detail, so I'm not sure which of these
> points it satisfies. It would be great if you could quickly describe
> how it works, and what the goals are.
>
> Essentially, I'm just sceptical that this isn't more trouble than it's worth.
>
> Ilija

Here's how it works, roughly:
for pull requests:
- creates a new dedicated CI job specifically to check for formatting errors
- If formatting errors are detected, the CI fails, with the last
message being a command to fix the styling issue, it looks like, and I
quote:
```
please run
curl https://termbin.com/zdzn | git apply -v
```
running that command, followed by git commit+git push should make the CI happy,
git apply will not stage/commit/push automatically however, so in
practice people will have to manually do:

curl https://termbin.com/zdzn | git apply -v;
(optionally run a `git diff` to just check that it looks right)
git commit -a --message 'formatting';
git push;

- we could add the last 2 steps to the actual error message, to make
all 3 steps a copypasta.. would not be opposed.

More technically, it
- creates a new dedicated CI job specifically to check for formatting errors
- Ubuntu 22.04, clang-format-diff, php-cli, git, netcat
- creates a diff between current PR code and master branch
- does *a bunch of tricks/hacks to get the environment suitable for
clang-format-diff* including switching to master,
 applying the diff to master, commiting the diff under a fake
username/email (because CI git doesn't have a username/email by
default and git refuse to commit without them)
- actually runs clang-format-diff against the last commit to format
all the code in the last commit
- generate a diff against the changes clang-format-diff just made
- revert the last "fake username/email commit"
- if that clang-format-diff is empty, it just prints "code formatting
check succeeded :)" and the CI finishes successfully
- if it's not empty, it prints, and I quote:
```
+ cat ../formatted.diff
diff --git a/test.c b/test.c
index 6df39be994..64cfab717d 100644
--- a/test.c
+++

Re: [PHP-DEV] automatic formatting checks for pull requests?

[Hans Henrik Bergan]

On Sat, Feb 17, 2024, 15:27 Gina P. Banyard  wrote:

> On Saturday, 17 February 2024 at 11:24, Hans Henrik Bergan <
> h...@loltek.net> wrote:
>
> > Can we add automatic formatting checks for pull requests?
> > Made a PR: https://github.com/php/php-src/pull/13417
> >
> > php-src use "tabs" instead of "spaces", that is... quite unusual,
> > and I'm probably not the first person to accidentally use spaces
> > instead of tabs, ref
> >
> https://github.com/php/php-src/pull/13401/files/d64a8ccdc1d21576827059ee86c0fa073c95ffcc#r1492699756
>
> That's quite standard in the C world AFAIK, yes it's not what is standard
> for PHP written code but that's kinda irrelevant.
>
> It would be nice to have some formatting rules to harmonize the codebase
> as it is somewhat the wild west,
> but as far as my understanding goes is that Clang format struggles to
> understand our codebase (namely macros) and is difficult to set-up for
> php-src.
>
> Best regards,
>
> Gina P. Banyard
>

It worked great with the macros I've tested so far:
ZEND_PARSE_PARAMETERS_START
Z_PARAM_NUMBER
ZEND_PARSE_PARAMETERS_END
Z_TYPE_P
Z_LVAL_P
UNEXPECTED
ZEND_ASSERT
RETURN_DOUBLE
RETURN_LONG
RETURN_THROWS

Is there any specific macros I can test?

Re: [PHP-DEV] Requesting RFC karma

[Hans Henrik Bergan]

On Sat, 17 Feb 2024 at 08:22, Hans Henrik Bergan  wrote:
>
> My name is "Hans Henrik Bergan", usually go by the nickname
> "divinity76", I've contributed to OSS (including PHP) for years, and
> am currently involved in 3 things that might require an RFC, and
> requesting RFC karma for wiki account "divinity76".
>
> 1/3: adding BLAKE3 to PHP, a *very* fast cryptographically secure
> hash: https://github.com/php/php-src/pull/13194
>
> 2/3: int|float for sleep, sleep(0.1) => sleep 0.1 seconds:
> https://github.com/php/php-src/pull/13401
>
> 3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
> 1970-01-01 00:00:00.123456 : https://github.com/php/php-src/pull/13383

and possibly
4/4: automatic code formatting check for pull requests:
https://github.com/php/php-src/pull/13417

Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds

[Hans Henrik Bergan]

On Fri, 16 Feb 2024 at 09:36, Alexandru Pătrănescu  wrote:
>
>
> On Fri, Feb 16, 2024 at 10:18 AM Hans Henrik Bergan  wrote:
>>
>> Can we make sleep accept int|float?
>> Made a PR: https://github.com/php/php-src/pull/13401
>>
>> For years when I wanted to sleep for 0.1 seconds, it annoyed me that I 
>> couldn't do
>> `sleep(0.1);`
>> instead I had to do
>> `usleep(figure out how many microseconds there are in 0.1 seconds and put it 
>> here);`
>>
>
> Based on previous discussions https://externals.io/message/111448
> it seems the desired way was for a RFC to be created for this change, as it 
> involves some small changes that break BC.
>
> There is also the PR done by Michael Voříšek from 3.5 years ago where some 
> technical discussions took place:
> https://github.com/php/php-src/pull/5961
>
> Regards,
> Alex
>

Interesting indeed. I implemented some improvements from that PR now
(higher precision sleep and fixing the windows 192-issue),
and got Michael Voříšek's attention :)
also applied for RFC Karma.

On Fri, 16 Feb 2024 at 14:20, Claude Pache  wrote:
>
> Hi,
>
>
> FWIW Python's `time.sleep` also works like this: 
> https://docs.python.org/3/library/time.html#time.sleep
>
>
> Python also implements the following:
>
> If the sleep is interrupted by a signal and no exception is raised by the 
> signal handler, the sleep is restarted with a recomputed timeout.
>
>
> I think we should also implement that. As a consequence, `sleep(...)` will 
> always return `0`.
>
> If we “fix” sleep(), let’s “fix” it completely.
>
> —Claude


it seems we already have a function for that, it's called `time_sleep_until()`,
quoting the documentation
>Note: All signals will be delivered after the script wakes up.

in contrast to normal sleep() that is signal interruptible.
Sorry, I'm not interested in making sleep() uninterruptible, at least
not until after I get int|float accepted upstream.

[PHP-DEV] automatic formatting checks for pull requests?

[Hans Henrik Bergan]

Can we add automatic formatting checks for pull requests?
Made a PR: https://github.com/php/php-src/pull/13417

php-src use "tabs" instead of "spaces", that is... quite unusual,
and I'm probably not the first person to accidentally use spaces
instead of tabs, ref
https://github.com/php/php-src/pull/13401/files/d64a8ccdc1d21576827059ee86c0fa073c95ffcc#r1492699756

[PHP-DEV] Requesting RFC karma

[Hans Henrik Bergan]

My name is "Hans Henrik Bergan", usually go by the nickname
"divinity76", I've contributed to OSS (including PHP) for years, and
am currently involved in 3 things that might require an RFC, and
requesting RFC karma for wiki account "divinity76".

1/3: adding BLAKE3 to PHP, a *very* fast cryptographically secure
hash: https://github.com/php/php-src/pull/13194

2/3: int|float for sleep, sleep(0.1) => sleep 0.1 seconds:
https://github.com/php/php-src/pull/13401

3/3: int|float for DateTime::setTimestamp, setTimestamp(0.123456) =>
1970-01-01 00:00:00.123456 : https://github.com/php/php-src/pull/13383

[PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds

[Hans Henrik Bergan]

Can we make sleep accept int|float?
Made a PR: https://github.com/php/php-src/pull/13401

For years when I wanted to sleep for 0.1 seconds, it annoyed me that I
couldn't do
`sleep(0.1);`
instead I had to do
`usleep(figure out how many microseconds there are in 0.1 seconds and put
it here);`

FWIW Python's `time.sleep` also works like this:
https://docs.python.org/3/library/time.html#time.sleep

Re: [PHP-DEV] [Discussion] Thoughts on casting to null

[Hans Henrik Bergan]

EventLoop::repeat($pingInterval,
function(...$args)use($client){$client->ping(...$args)});

[PHP-DEV] int|float for DateTime::setTimestamp

[Hans Henrik Bergan]

just like the constructor accepts
new DateTime("@0.123456"); // 1970-01-01 00:00:00.123456
new DateTime("@".microtime(true));

IMO setTimestamp should accept the same:
$dt->setTimestamp(0.123456); // 1970-01-01 00:00:00.123456
$dt->setTimestamp(microtime(true));

Can we change setTimestamp to accept int|float?
made a PR https://github.com/php/php-src/pull/13383

Re: [PHP-DEV] BLAKE3 hash

[Hans Henrik Bergan]

with
https://github.com/php/php-src/commit/52dba99d47563f38d8ed5f84690a3cb2c1785475
,
the PR (  https://github.com/php/php-src/pull/13194  ) got the first merge
conflict. I fixed it, but what's next?

Could vote on it, if there is little more to discuss?

quick recap
AMD Ryzen 9 7950x:
portable -O2: 1126MB/s,
SSE2: 3144MB/s
SSE4.1: 3332MB/s
AVX2: 6554MB/s
AVX512: 8913MB/s,
Oracle Cloud's ARM VM.Standard.A1.Flex
portable -O2: 596MB/s
Neon: 1138MB/s

Re: [PHP-DEV] BLAKE3 hash

[Hans Henrik Bergan]

just tested ARM Neon optimizations on Oracle Cloud's cheapest ARM VPS:
VM.Standard.A1.Flex, Ubuntu 22.04, GCC11.4,
results:
-O2 portable: 596MB/s
-O2 -march=native portable: 601MB/s
-O2 ARM Neon optimized implementation: 1138MB/s

Again, even with -march=native, the compiler cannot make the portable
implementation nearly as fast as the hand-optimized cpu-specific
implementation.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] BLAKE3 hash

[Hans Henrik Bergan]

On Wed, 24 Jan 2024 at 17:59, Marco Pivetta  wrote:
>
> Depends on the actual numbers: is there any way to make a comparison that
> is relatively stable across architectures?
>
> Would it be feasible to start with the
> cross-platform-let-the-compiler-do-its-job version (that somebody may
> actually be capable of auditing), and then introduce other versions when
> the jump is significant enough?
>

don't know about "relatively stable across architectures" but wrote
some benchmarking code, keep reading.



On Wed, 24 Jan 2024 at 17:55, tag Knife  wrote:
> Should we even be considering the specific instruction implementations?
> I've always been in the camp
> of you are not smarter than the compiler. As even the best human written
> ASM code can be slower
> than the obscure instructions the compiler might choose to use in a weird
> and wonderful way.

The BLAKE3 team is smarter than GCC11.4, even with -march=native
-mtune=native, which is *not* commonly used in PHP,
the compiler didn't stand a chance against the hand-optimized assembly versions,

wrote some benchmarks, but the TL;DR is:
portable -O2 usually used by PHP managed 1126MB/s,
portable -O2 -march=native managed 533MB/s (wtf? gcc obviously got
something wrong here),
hand-written -O2 SSE2  managed 3144MB/s,
hand-written -O2 SSE41 managed 3332MB/s,
hand-written -O2 avx2 managed 6554MB/s,
hand-writen -O2 AVX512 managed 8913MB/s,
on my AMD Ryzen 9 7950x,
benchmarking code:
https://gist.github.com/divinity76/5729472dd5d77e94cd0acb245aac2226
raw output:
array(6) {
  ["O2-portable-march"]=>
  array(2) {
["microseconds_for_16_kib"]=>
int(29295)
["mb_per_second"]=>
float(533.3674688513398)
  }
  ["O2-portable"]=>
  array(2) {
["microseconds_for_16_kib"]=>
int(13876)
["mb_per_second"]=>
float(1126.0449697319111)
  }
  ["O2-sse2"]=>
  array(2) {
["microseconds_for_16_kib"]=>
int(4969)
["mb_per_second"]=>
float(3144.4958744214127)
  }
  ["O2-sse41"]=>
  array(2) {
["microseconds_for_16_kib"]=>
int(4688)
["mb_per_second"]=>
float(3332.977815699659)
  }
  ["O2-avx2"]=>
  array(2) {
["microseconds_for_16_kib"]=>
int(2384)
["mb_per_second"]=>
float(6554.1107382550335)
  }
  ["O2-avx512"]=>
  array(2) {
["microseconds_for_16_kib"]=>
int(1753)
["mb_per_second"]=>
float(8913.291500285226)
  }
}

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] BLAKE3 hash

[Hans Henrik Bergan]

Maybe vote on it? (that was suggested in the PR too,
https://github.com/php/php-src/pull/13194#issuecomment-1900430400 )

Can think of 6 things

1: Should BLAKE3 be added to PHP? yes/no
2: Should ARM Neon (2007) optimized implementation be bundled? yes/no
3: Should x86_64 SSE2 (2000) optimized implementation be bundled? yes/no
4: Should x86_64 SSE4.1 (2007) optimized implementation be bundled? yes/no
5: Should x86_64 AVX2 (2011) optimized implementation be bundled? yes/no
6: Should x86_64 AVX512 (2016) optimized implementation be bundled? yes/no

(wrote the year processors were actually released, not the year
instructions were proposed/announced)

Arguments against SSE2 and SSE4.1: pretty much all modern CPUs supporting
SSE2/SSE4.1 also support AVX2.

Argument against AVX512: CloudFlare said in a blogpost that when a core
starts executing AVX512 instructions, it decreases the clock speed of
neighboring cores so much that, quote:
>OpenSSL serves 10% fewer requests per second. And that is a huge number!
It is equivalent to giving up on two cores, for nothing

and another quote:

>If you do not require AVX-512 for some specific high performance tasks, I
suggest you disable AVX-512 execution on your server or desktop, to avoid
accidental AVX-512 throttling.

(ref https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling
)
that AVX512 issue is probably cpu-specific and will probably be mitigated
in newer CPU releases
(idk if AMD is even affected, or if it is purely a Intel issue)

thus they may be worthy of a vote

Re: [PHP-DEV] BLAKE3 hash

[Hans Henrik Bergan]

On Mon, 22 Jan 2024 at 07:10, tag Knife  wrote:
>
> That's why I suggested implementing separate lengths of the like we have for 
> SHA3, so we could have BLAKE3_256 and BLAKE3_512 and maybe inbetweens.

we can look into exposing blake3's XOF (arbitrary length) capabilities
after (and if) initial blake3 support gets merged.
would probably look something like hash_final($ctx,
options:["length"=>512/8]); hash("blake3", "x", options:
["length"=>512/8]);
and deserves its own dedicated pull request.

On Mon, 22 Jan 2024 at 03:43, Gina P. Banyard  wrote:
>
> Just an etiquette note, please don't top post on the mailing list. [1]
> I have no idea what this sentence is replying to, and it makes following the 
> discussion difficult.

I see, thanks for the heads up.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] BLAKE3 hash

[Hans Henrik Bergan]

Having looked into it, it seems difficult after all,
I would want a new $options argument for hash_final(), and some
internal changes to struct php_hash_blake3_ops,
and that internal change would have to be updated for all other hashes
PHP support..
I'm not up for doing that now.

And I think it should be a separate PR, after the initial support gets merged.

On Fri, 19 Jan 2024 at 21:42, Hans Henrik Bergan  wrote:
>
> >BLAKE3 has 2 default sizes
>
> Nope, only 1 canonical size, 256 bits.
> *BUT* BLAKE3 is XOF, it can be exactly as long as you want it to be:
>
> $ echo test | b3sum --length 5
> dea2b412aa  -
> $ echo test | b3sum --length 10
> dea2b412aa90f1b43a06  -
> $ echo test | b3sum --length 32
> dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2  -
> $ echo test | b3sum --length 64
> dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2ea67cf3c73a3acbfa2bdab694345d8ecf5e353dd1a3d5a9628aec9bffc3e4cca
>  -
> $ echo test | b3sum --length 999
> dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2ea67cf3c73a3acbfa2bdab694345d8ecf5e353dd1a3d5a9628aec9bffc3e4ccaa32f434df18da6161cabb08b6278dcebca9833fe8d9f65d64db922cecf78c55b521f60dbd77d8ad8378a8f481f2941fedc817d7e1fdeb9c9c9915f3e0a8a8b3cbd4849e21dbe4e359b21224dee5b75bcee0f2083bb8c25559b109727d23b02bde4d2e212529106a1b23be564007909fa23e39c8fdca42a86e75f1568d77a85b0efb0acfa0258907f6d9bfae259234d782d53276f823fe32e29b7165818cbc75e4860188d60f6bb31b00308b1a7293b75e007eaf2de846709bb1856ed398e1c354a093b4f4853b9127ba2e9d85b5336b3e09eb802eef8168f1954c34cc9c61bb933de56790caaff3e03b43f85febfc175e3534e687527a757c2b2e5474efa6db51873da140f5ebc65dca5545b73dd64ac7585fe1d123475e128878962ff8952cd2c8372c4808c4893c8038e6ffb52ef7cf9416ad71588d779c8d60d19c997524b6f756b1d0d5934d41a8e3644fb3fc23e2403bf8b94b95a36f66fb108b6ed824b117f3de9314566bd7042bdd5116e096f0846121ba7034559b234074eac403d2d0f9a4386745375c54d2c22cc970a1cd9836cc9ad1bc3b8c511e5674f05cd5cb8d844c3e802199f0d8b9f3b6e2abd8e830b5768c1539b2d445181fbdcf77c51c330c67aa7b62691d18ecdb7d3124ac4e5fd83a8251ec072740aa4029624ad0a51ebfc8281a5e098ceda2b468e0f936a93b3498b0f11484c4e04cd7be657614ddebe9c08eb0c912431239605e1924009d32afeb965e9c7bbde77bc8efc2ebbc7eb3555286bb7b97fc30fe33806b36aef129d975251a737f0a285fd7cb617b9326211d22924704a2760e235ffa0c125eabb556698120229880b3af0f6dc81336af17fc90f3e889142a5e338a28816c0b6b3944d2f05b7a70189d3e8a19a1e6f6ca0041d4eb165ab4e4aad2f6ec87dc2986263e395c5a5d626bf8847d8b4a70126858f6adda1f39ce0cacf266895856c9ea118418b80c1a37260c7ef73598beb6b2cb3665eece981e249fec4ab8ad2424f1243b0835a7f079a3a9e9c288395a88e70f75eb5610251a416a7189d6e1c3c25a6729d3c9bae65970f8fa48d3ef8f8469ab62c19c3adc04a5c7debea10a910df7d389b183c18cd33fe6b946ebfc5b8a0505968a63122fe0f618e8cf07a978777381bdbafac8024226eee532b76d63ee4a0b45f1f623928afcce21977284868747d7949dd912c8b0894b6a782d2985085f0e629c0c7be7ab19b37e4c5f01a1636f62ee55783b86df8d53698e8b4bbe03fd69322609bb6fdee35cb433d44ec7322d6f1d040f87072bba06ab793bd857c7f754b080b8b04b28c
>  -
>
> And what's more, thanks to PHP8.1.0's new $options argument for hash()
> we can expose blake3's XOF like
>  hash("blake3", "test", options: ["length"=>512/8]): blake3_512
>  hash("blake3", "test", options: ["length"=>256/8]): blake3_256
>  hash("blake3", "test", options: ["length"=>8/8]): blake3_8
>  hash("blake3", "test", options: ["length"=>1000]): blake3_8000
>
>
> that shouldn't be too difficult to implement either! good idea
>
> On Fri, 19 Jan 2024 at 20:20, tag Knife  wrote:
> >
> > On Fri, 19 Jan 2024 at 18:43, Hans Henrik Bergan  wrote:
> >
> > >  Can we add the BLAKE3 hash?
> > >
> > > Created a PR here: https://github.com/php/php-src/pull/13194
> > >
> > > BLAKE3 is a very fast ("blazing fast") cryptographically secure hash. It 
> > > is
> > > the latest iteration of the BLAKE hash, which was a SHA3 finalist~ see
> > > https://github.com/BLAKE3-team/BLAKE3 for more info on BLAKE3.
> > >
> > > In the PR is a portable C implementation, along with optimized ARM-neon 
> > > and
> > > x86_64 SSE2, SSE41, AVX2, and AVX512 implementations for GCC+unix and
> > > GCC+windows and MSVC (*MSVC is currently only using the portable
> > > implementation, but it should be easy for a developer equipped with MSVC 
> > > to
> > > enable the optimized implementations. I don't have MSVC personally)
> > >
> > > That means the PR includes ~35 copies of the same algorithm, in
> > > hand-written assembly, optimized for various CPU/compiler/OS combinations.
> > > Which means the PR is hug*e.*
> > >
> > > It would be possib

Re: [PHP-DEV] BLAKE3 hash

[Hans Henrik Bergan]

>BLAKE3 has 2 default sizes

Nope, only 1 canonical size, 256 bits.
*BUT* BLAKE3 is XOF, it can be exactly as long as you want it to be:

$ echo test | b3sum --length 5
dea2b412aa  -
$ echo test | b3sum --length 10
dea2b412aa90f1b43a06  -
$ echo test | b3sum --length 32
dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2  -
$ echo test | b3sum --length 64
dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2ea67cf3c73a3acbfa2bdab694345d8ecf5e353dd1a3d5a9628aec9bffc3e4cca
 -
$ echo test | b3sum --length 999
dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2ea67cf3c73a3acbfa2bdab694345d8ecf5e353dd1a3d5a9628aec9bffc3e4ccaa32f434df18da6161cabb08b6278dcebca9833fe8d9f65d64db922cecf78c55b521f60dbd77d8ad8378a8f481f2941fedc817d7e1fdeb9c9c9915f3e0a8a8b3cbd4849e21dbe4e359b21224dee5b75bcee0f2083bb8c25559b109727d23b02bde4d2e212529106a1b23be564007909fa23e39c8fdca42a86e75f1568d77a85b0efb0acfa0258907f6d9bfae259234d782d53276f823fe32e29b7165818cbc75e4860188d60f6bb31b00308b1a7293b75e007eaf2de846709bb1856ed398e1c354a093b4f4853b9127ba2e9d85b5336b3e09eb802eef8168f1954c34cc9c61bb933de56790caaff3e03b43f85febfc175e3534e687527a757c2b2e5474efa6db51873da140f5ebc65dca5545b73dd64ac7585fe1d123475e128878962ff8952cd2c8372c4808c4893c8038e6ffb52ef7cf9416ad71588d779c8d60d19c997524b6f756b1d0d5934d41a8e3644fb3fc23e2403bf8b94b95a36f66fb108b6ed824b117f3de9314566bd7042bdd5116e096f0846121ba7034559b234074eac403d2d0f9a4386745375c54d2c22cc970a1cd9836cc9ad1bc3b8c511e5674f05cd5cb8d844c3e802199f0d8b9f3b6e2abd8e830b5768c1539b2d445181fbdcf77c51c330c67aa7b62691d18ecdb7d3124ac4e5fd83a8251ec072740aa4029624ad0a51ebfc8281a5e098ceda2b468e0f936a93b3498b0f11484c4e04cd7be657614ddebe9c08eb0c912431239605e1924009d32afeb965e9c7bbde77bc8efc2ebbc7eb3555286bb7b97fc30fe33806b36aef129d975251a737f0a285fd7cb617b9326211d22924704a2760e235ffa0c125eabb556698120229880b3af0f6dc81336af17fc90f3e889142a5e338a28816c0b6b3944d2f05b7a70189d3e8a19a1e6f6ca0041d4eb165ab4e4aad2f6ec87dc2986263e395c5a5d626bf8847d8b4a70126858f6adda1f39ce0cacf266895856c9ea118418b80c1a37260c7ef73598beb6b2cb3665eece981e249fec4ab8ad2424f1243b0835a7f079a3a9e9c288395a88e70f75eb5610251a416a7189d6e1c3c25a6729d3c9bae65970f8fa48d3ef8f8469ab62c19c3adc04a5c7debea10a910df7d389b183c18cd33fe6b946ebfc5b8a0505968a63122fe0f618e8cf07a978777381bdbafac8024226eee532b76d63ee4a0b45f1f623928afcce21977284868747d7949dd912c8b0894b6a782d2985085f0e629c0c7be7ab19b37e4c5f01a1636f62ee55783b86df8d53698e8b4bbe03fd69322609bb6fdee35cb433d44ec7322d6f1d040f87072bba06ab793bd857c7f754b080b8b04b28c
 -

And what's more, thanks to PHP8.1.0's new $options argument for hash()
we can expose blake3's XOF like
 hash("blake3", "test", options: ["length"=>512/8]): blake3_512
 hash("blake3", "test", options: ["length"=>256/8]): blake3_256
 hash("blake3", "test", options: ["length"=>8/8]): blake3_8
 hash("blake3", "test", options: ["length"=>1000]): blake3_8000


that shouldn't be too difficult to implement either! good idea

On Fri, 19 Jan 2024 at 20:20, tag Knife  wrote:
>
> On Fri, 19 Jan 2024 at 18:43, Hans Henrik Bergan  wrote:
>
> >  Can we add the BLAKE3 hash?
> >
> > Created a PR here: https://github.com/php/php-src/pull/13194
> >
> > BLAKE3 is a very fast ("blazing fast") cryptographically secure hash. It is
> > the latest iteration of the BLAKE hash, which was a SHA3 finalist~ see
> > https://github.com/BLAKE3-team/BLAKE3 for more info on BLAKE3.
> >
> > In the PR is a portable C implementation, along with optimized ARM-neon and
> > x86_64 SSE2, SSE41, AVX2, and AVX512 implementations for GCC+unix and
> > GCC+windows and MSVC (*MSVC is currently only using the portable
> > implementation, but it should be easy for a developer equipped with MSVC to
> > enable the optimized implementations. I don't have MSVC personally)
> >
> > That means the PR includes ~35 copies of the same algorithm, in
> > hand-written assembly, optimized for various CPU/compiler/OS combinations.
> > Which means the PR is hug*e.*
> >
> > It would be possible to only ship a subset of them (For example, keeping
> > just the gcc+unix+SSE2 and gcc+unix+AVX2 and ARM-neon and trash the rest,
> > would benefit a lot systems in-the-wild, and reduce the size of the PR
> > substantially)
> >
> > It would also be possible to only ship the portable pure C implementation,
> > but that would also be detrimental to the performance, which is the main
> > motivator for adding BLAKE3 in the first place.
> >
> > But the groundwork to ship them all is already done (see the PR)
> >
> > Thoughts?
> >
>
> BLAKE3 has 2 default sizes, BLAKE3_256 and BLAKE3_512. Internally the
> hashblock size is 512,
> With other algo's we have added these different hash sizes, would it be
> possible for you to expose the 2 hash sizes.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] BLAKE3 hash

[Hans Henrik Bergan]

 Can we add the BLAKE3 hash?

Created a PR here: https://github.com/php/php-src/pull/13194

BLAKE3 is a very fast ("blazing fast") cryptographically secure hash. It is
the latest iteration of the BLAKE hash, which was a SHA3 finalist~ see
https://github.com/BLAKE3-team/BLAKE3 for more info on BLAKE3.

In the PR is a portable C implementation, along with optimized ARM-neon and
x86_64 SSE2, SSE41, AVX2, and AVX512 implementations for GCC+unix and
GCC+windows and MSVC (*MSVC is currently only using the portable
implementation, but it should be easy for a developer equipped with MSVC to
enable the optimized implementations. I don't have MSVC personally)

That means the PR includes ~35 copies of the same algorithm, in
hand-written assembly, optimized for various CPU/compiler/OS combinations.
Which means the PR is hug*e.*

It would be possible to only ship a subset of them (For example, keeping
just the gcc+unix+SSE2 and gcc+unix+AVX2 and ARM-neon and trash the rest,
would benefit a lot systems in-the-wild, and reduce the size of the PR
substantially)

It would also be possible to only ship the portable pure C implementation,
but that would also be detrimental to the performance, which is the main
motivator for adding BLAKE3 in the first place.

But the groundwork to ship them all is already done (see the PR)

Thoughts?

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Hans Henrik Bergan]

i think Shift_JIS can also be automatically converted to UTF-8, does
this seem right?
https://github.com/divinity76/php2utf8/commit/6e08c4c16312961170cce821195816a8d24e23f6

On Wed, 29 Nov 2023 at 01:21, youkidearitai  wrote:
>
> > Use zend.script_encoding=sjis and zend_bultibyte=true
> >
> > ❯ ~/php82/bin/php -d zend.script_encoding=sjis  -d zend.multibyte=true
> > deprecate_zend_scriptencoding.php
> > array(7) {
> >   ["biao_hex"]=>
> >   string(6) "e8a1a8"
> >   ["zend.multibyte"]=>
> >   string(1) "1"
> >   ["zend.script_encoding"]=>
> >   string(4) "sjis"
> >   ["zend.detect_unicode"]=>
> >   string(1) "1"
> >   ["mbstring.internal_encoding"]=>
> >   string(0) ""
> >   ["mbstring.func_overload"]=>
> >   bool(false)
> >   ["PHP_VERSION"]=>
> >   string(5) "8.2.8"
> > }
> >
>
> Strictly, include internal_encoding.
>
> ❯ ~/php82/bin/php -d zend.script_encoding=sjis -d
> internal_encoding=sjis -d zend.multibyte=true
> deprecate_zend_scriptencoding.php
> array(7) {
>   ["biao_hex"]=>
>   string(4) "955c"
>   ["zend.multibyte"]=>
>   string(1) "1"
>   ["zend.script_encoding"]=>
>   string(4) "sjis"
>   ["zend.detect_unicode"]=>
>   string(1) "1"
>   ["mbstring.internal_encoding"]=>
>   string(0) ""
>   ["mbstring.func_overload"]=>
>   bool(false)
>   ["PHP_VERSION"]=>
>   string(5) "8.2.8"
> }
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Hans Henrik Bergan]

actually scratch that, run
```
var_dump(array(
"biao_hex" => bin2hex("表"),
"zend.multibyte" => ini_get("zend.multibyte"),
"zend.script_encoding" => ini_get("zend.script_encoding"),
"zend.detect_unicode" => ini_get("zend.detect_unicode"),
"mbstring.internal_encoding" => ini_get("mbstring.internal_encoding"),
"mbstring.func_overload" => ini_get("mbstring.func_overload"),
"PHP_VERSION" => PHP_VERSION,
"raw_script_bytes" => bin2hex(file_get_contents(__FILE__)),
));
```
what do you get?

On Wed, 29 Nov 2023 at 01:04, Hans Henrik Bergan  wrote:
>
> Do you have access to a project actually using Shift_JIS? Interesting!
> I thought they were practically unicorns / non-existent running PHP4,
>
> Can you run
> ```
> var_dump(array(
> "biao_hex" => bin2hex("表"),
> "zend.multibyte" => ini_get("zend.multibyte"),
> "zend.script_encoding" => ini_get("zend.script_encoding"),
> "zend.detect_unicode" => ini_get("zend.detect_unicode"),
> "mbstring.internal_encoding" => ini_get("mbstring.internal_encoding"),
> "mbstring.func_overload" => ini_get("mbstring.func_overload"),
> "PHP_VERSION" => PHP_VERSION,
> ));
> ```
> there? What do you get?
>
> On Wed, 29 Nov 2023 at 00:47, youkidearitai  wrote:
> >
> > 2023年11月29日(水) 8:07 Hans Henrik Bergan :
> > >
> > > @youkidearitai right now the code specifically deals with
> > > - UTF8: removing UTF8 BOM and removing `declare(encoding='UTF-8');
> > > - UTF16LE/UTF16BE/UTF32LE/UTF32BE: converting to UTF8 removing the BOM
> > > and removing declare(encoding='...')
> > > - ISO-8859-1: converting to UTF-8 and removing
> > > declare(encoding='ISO-8859-1'), i couldn't really find information on
> > > a ISO-8859-1 BOM, so to the best of my knowledge it does not exist
> > >
> > > it does not deal with any other encodings as of writing, but more can
> > > be added if needed.
> > >
> >
> > Hi, Hans
> >
> > I see. I understand the argument.
> > At least, Japanese character encoding seems not using declare(encoding=...).
> >
> > Probably, we use zend_encoding implicitly.
> > If delete zend_encoding, In SJIS (Shift_JIS) probably will occur 5c problem.
> >
> > For example is below:
> >
> > $val = "表"; // 表 is 0x955c, script see 0x5c22, therefore, Throw on Parse 
> > Error
> >
> > Please see about 5c problem 
> > https://blog.kano.ac/archive/posts/1654_5c-problem/
> >
> > I would like to maintain backwards compatibility. zend_encoding seems
> > can't delete.
> >
> > Regards
> > Yuya
> >
> > --
> > ---
> > Yuya Hamada (tekimen)
> > - https://tekitoh-memdhoi.info
> > - https://github.com/youkidearitai
> > -
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Hans Henrik Bergan]

Do you have access to a project actually using Shift_JIS? Interesting!
I thought they were practically unicorns / non-existent running PHP4,

Can you run
```
var_dump(array(
"biao_hex" => bin2hex("表"),
"zend.multibyte" => ini_get("zend.multibyte"),
"zend.script_encoding" => ini_get("zend.script_encoding"),
"zend.detect_unicode" => ini_get("zend.detect_unicode"),
"mbstring.internal_encoding" => ini_get("mbstring.internal_encoding"),
"mbstring.func_overload" => ini_get("mbstring.func_overload"),
"PHP_VERSION" => PHP_VERSION,
));
```
there? What do you get?

On Wed, 29 Nov 2023 at 00:47, youkidearitai  wrote:
>
> 2023年11月29日(水) 8:07 Hans Henrik Bergan :
> >
> > @youkidearitai right now the code specifically deals with
> > - UTF8: removing UTF8 BOM and removing `declare(encoding='UTF-8');
> > - UTF16LE/UTF16BE/UTF32LE/UTF32BE: converting to UTF8 removing the BOM
> > and removing declare(encoding='...')
> > - ISO-8859-1: converting to UTF-8 and removing
> > declare(encoding='ISO-8859-1'), i couldn't really find information on
> > a ISO-8859-1 BOM, so to the best of my knowledge it does not exist
> >
> > it does not deal with any other encodings as of writing, but more can
> > be added if needed.
> >
>
> Hi, Hans
>
> I see. I understand the argument.
> At least, Japanese character encoding seems not using declare(encoding=...).
>
> Probably, we use zend_encoding implicitly.
> If delete zend_encoding, In SJIS (Shift_JIS) probably will occur 5c problem.
>
> For example is below:
>
> $val = "表"; // 表 is 0x955c, script see 0x5c22, therefore, Throw on Parse Error
>
> Please see about 5c problem 
> https://blog.kano.ac/archive/posts/1654_5c-problem/
>
> I would like to maintain backwards compatibility. zend_encoding seems
> can't delete.
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Hans Henrik Bergan]

@youkidearitai right now the code specifically deals with
- UTF8: removing UTF8 BOM and removing `declare(encoding='UTF-8');
- UTF16LE/UTF16BE/UTF32LE/UTF32BE: converting to UTF8 removing the BOM
and removing declare(encoding='...')
- ISO-8859-1: converting to UTF-8 and removing
declare(encoding='ISO-8859-1'), i couldn't really find information on
a ISO-8859-1 BOM, so to the best of my knowledge it does not exist

it does not deal with any other encodings as of writing, but more can
be added if needed.

On Tue, 28 Nov 2023 at 23:58, youkidearitai  wrote:
>
> 2023年11月29日(水) 7:41 Hans Henrik Bergan :
> >
> > btw if we come to some consensus to my php2utf8.php script is actually
> > worthwhile to expand on, i can volunteer to add more encodings (SJIS,
> > BIG5, anything supported by mbstring),
> > but it wouldn't surprise me if a better approach exist and the script
> > should be rewritten entirely~
> >
> > >add that what's special about UTF-8 isn't that it's "fixed-endian".
> >
> > should've added this to the last post, but the "zend.detect_unicode"
> > ini-option is specifically to scan for BOMs, and BOMs are
> > significantly less useful in fixed-endian encodings (like UTF8) than
> > bi-endian encodings (like UTF16/UTF32) ^^
> >
> > On Tue, 28 Nov 2023 at 21:47, Hans Henrik Bergan  
> > wrote:
> > >
> > > > What is the migration path for legacy code that use those directives?
> > >
> > > The migration path is to convert the legacy-encoding PHP files to UTF-8.
> > > Luckily this can be largely automated, here is my attempt:
> > > https://github.com/divinity76/php2utf8/blob/main/src/php2utf8.php
> > > but that code definitely needs some proof-reading and additions - idk
> > > if the approach used is even a good approach, it was just the first i
> > > could think of, feel free to write one from scratch
> > >
> > >
> > > >Can you share a little more details about how this works?
> > >
> > > I hope someone else can do that, but it allows PHP to parse and
> > > execute scripts not written in UTF-8 and scripts utilizing
> > > BOM/byte-order-masks.
> > >
> > > >add that what's special about UTF-8 isn't that it's "fixed-endian".
> > >
> > > one of multiple good things about UTF-8 is that it's fixed-endian, and
> > > UTF8 don't need a BOM to specify endianess (unlike UTF16 and UTF32
> > > which are bi-endian, and a BOM helps identify endianess used~)
> > >
> > > >If the solution is as easy as just converting the encoding of the
> > > source file, then why did we even need to have this setting at all?
> > > Why did PHP parser support encodings that demanded the introduction of
> > >
> > > I've read your question but don't have an answer to it, hopefully
> > > someone else knows.
> > >
> > >
> > > On Tue, 28 Nov 2023 at 21:09, Claude Pache  wrote:
> > > >
> > > >
> > > >
> > > > > Le 28 nov. 2023 à 20:56, Kamil Tekiela  a écrit 
> > > > > :
> > > > >
> > > > >> Convert your PHP source files to UTF-8.
> > > > >
> > > > > If the solution is as easy as just converting the encoding of the
> > > > > source file, then why did we even need to have this setting at all?
> > > > > Why did PHP parser support encodings that demanded the introduction of
> > > > > this declare?
> > > >
> > > > It is not necessary as simple: because your code base may contain 
> > > > literal strings, and changing the encoding of the source file will 
> > > > effectively change the contents of the strings.
> > > >
> > > > —Claude
> > > >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
>
> Hi, Hans
>
> Is this convert PHP code from any encoding to UTF-8?
> If correct, PHP code is coded various character encoding,
> It is very difficult.
> This is because it is not necessarily implemented in UTF-8.
>
> In the world, we have many character encoding.
> PHP code will be difficult to unify.
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Hans Henrik Bergan]

btw if we come to some consensus to my php2utf8.php script is actually
worthwhile to expand on, i can volunteer to add more encodings (SJIS,
BIG5, anything supported by mbstring),
but it wouldn't surprise me if a better approach exist and the script
should be rewritten entirely~

>add that what's special about UTF-8 isn't that it's "fixed-endian".

should've added this to the last post, but the "zend.detect_unicode"
ini-option is specifically to scan for BOMs, and BOMs are
significantly less useful in fixed-endian encodings (like UTF8) than
bi-endian encodings (like UTF16/UTF32) ^^

On Tue, 28 Nov 2023 at 21:47, Hans Henrik Bergan  wrote:
>
> > What is the migration path for legacy code that use those directives?
>
> The migration path is to convert the legacy-encoding PHP files to UTF-8.
> Luckily this can be largely automated, here is my attempt:
> https://github.com/divinity76/php2utf8/blob/main/src/php2utf8.php
> but that code definitely needs some proof-reading and additions - idk
> if the approach used is even a good approach, it was just the first i
> could think of, feel free to write one from scratch
>
>
> >Can you share a little more details about how this works?
>
> I hope someone else can do that, but it allows PHP to parse and
> execute scripts not written in UTF-8 and scripts utilizing
> BOM/byte-order-masks.
>
> >add that what's special about UTF-8 isn't that it's "fixed-endian".
>
> one of multiple good things about UTF-8 is that it's fixed-endian, and
> UTF8 don't need a BOM to specify endianess (unlike UTF16 and UTF32
> which are bi-endian, and a BOM helps identify endianess used~)
>
> >If the solution is as easy as just converting the encoding of the
> source file, then why did we even need to have this setting at all?
> Why did PHP parser support encodings that demanded the introduction of
>
> I've read your question but don't have an answer to it, hopefully
> someone else knows.
>
>
> On Tue, 28 Nov 2023 at 21:09, Claude Pache  wrote:
> >
> >
> >
> > > Le 28 nov. 2023 à 20:56, Kamil Tekiela  a écrit :
> > >
> > >> Convert your PHP source files to UTF-8.
> > >
> > > If the solution is as easy as just converting the encoding of the
> > > source file, then why did we even need to have this setting at all?
> > > Why did PHP parser support encodings that demanded the introduction of
> > > this declare?
> >
> > It is not necessary as simple: because your code base may contain literal 
> > strings, and changing the encoding of the source file will effectively 
> > change the contents of the strings.
> >
> > —Claude
> >

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Hans Henrik Bergan]

> What is the migration path for legacy code that use those directives?

The migration path is to convert the legacy-encoding PHP files to UTF-8.
Luckily this can be largely automated, here is my attempt:
https://github.com/divinity76/php2utf8/blob/main/src/php2utf8.php
but that code definitely needs some proof-reading and additions - idk
if the approach used is even a good approach, it was just the first i
could think of, feel free to write one from scratch


>Can you share a little more details about how this works?

I hope someone else can do that, but it allows PHP to parse and
execute scripts not written in UTF-8 and scripts utilizing
BOM/byte-order-masks.

>add that what's special about UTF-8 isn't that it's "fixed-endian".

one of multiple good things about UTF-8 is that it's fixed-endian, and
UTF8 don't need a BOM to specify endianess (unlike UTF16 and UTF32
which are bi-endian, and a BOM helps identify endianess used~)

>If the solution is as easy as just converting the encoding of the
source file, then why did we even need to have this setting at all?
Why did PHP parser support encodings that demanded the introduction of

I've read your question but don't have an answer to it, hopefully
someone else knows.


On Tue, 28 Nov 2023 at 21:09, Claude Pache  wrote:
>
>
>
> > Le 28 nov. 2023 à 20:56, Kamil Tekiela  a écrit :
> >
> >> Convert your PHP source files to UTF-8.
> >
> > If the solution is as easy as just converting the encoding of the
> > source file, then why did we even need to have this setting at all?
> > Why did PHP parser support encodings that demanded the introduction of
> > this declare?
>
> It is not necessary as simple: because your code base may contain literal 
> strings, and changing the encoding of the source file will effectively change 
> the contents of the strings.
>
> —Claude
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Hans Henrik Bergan]

With the dominance of UTF-8 (a fixed-endian encoding), surely no new
code should utilize any of declare(encoding='...') / zend.multibyte /
zend.script_encoding / zend.detect_unicode.
I propose we deprecate all 4.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

[Hans Henrik Bergan]

I think it'd be a good idea if they used FILTER_VALIDATE_BOOLEAN and
FILTER_VALIDATE_INTEGER type logic, with an error if conversion fails..

I wonder if PDO::PARAM_BOOL_OR_NULL would be worthwhile

On Sun, Nov 5, 2023, 10:10 Saki Takamachi  wrote:

> Hi,
>
> To think more deeply about this issue, I investigated various cases in
> major databases. It's too big to write in an email, so I posted it in the
> comments of the issue.
>
> https://github.com/php/php-src/issues/12603#issuecomment-1793679776
>
> Regards.
>
> Saki
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

[Hans Henrik Bergan]

I had no idea PDO's PARAM_INT and PARAM_BOOL was so buggy, good catch!

On Sat, Nov 4, 2023, 07:59 Saki Takamachi  wrote:

> Hi internals,
>
> As shown in the following issue, the behavior of `PDO::PARAM_` is
> inconsistent and I would like to fix this.
> https://github.com/php/php-src/issues/12603
>
> First, I tried fixed pdo_pgsql.
> https://github.com/php/php-src/pull/12605
>
> Eventually I plan to make similar changes to all bundled pdos.
>
> What do you think about these? If there is a reason for the current
> implementation that should not be changed, it would be very helpful if you
> could tell me why.
>
> Also, if an RFC is required, it would be helpful if you could point it out
> as well. Personally, I don't think an RFC is necessary since this is some
> kind of bug fix. However, I believe the target should be the master branch
> as it changes the user experience somewhat.
>
> [*] I'm not thinking about LOB here, but once I leave them with their
> existing behavior, I change the behavior of other types. Because LOB have
> complex behavior, the scope becomes too large. After making this change, I
> will test again and post another issue if necessary.
>
> [*] I would like the type of PARAM_BOOL to be exactly bool, but this would
> also require changing the behavior of the emulator, and I would not be able
> to issue a PR for each driver, making the scope too large. For this as
> well, I will just align it to `int(1)` or `string(1) 't'`, etc., and once
> these changes are completed, I will verify it and post an issue.
>
> [*] odbc etc. are not compatible with emulation in the first place. There
> are no plans to change this in this context.
>
> Regards.
>
> Saki
>

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

[Hans Henrik Bergan]

been years since i checked, but last time i checked, BCMath supports
floating point numbers,
and PHP's GMP wrappers does not (this is not a limitation of GMP
itself, but of PHP's GMP wrappers)

- has the GMP api floating issues been fixed? a quick test suggest
/no/: https://3v4l.org/FQaI4

On Thu, 12 Oct 2023 at 21:47, Pierre Joye  wrote:
>
> On Fri, Oct 13, 2023, 2:01 AM Jordan LeDoux  wrote:
>
> >
> >
> >
> > I believe MPFR is what is used by ext-decimal. The only thing that makes
> > ext-decimal a somewhat difficult replacement for BCMath is that one of them
> > uses precision and the other uses scale. (Total accurate digits versus
> > total significant digits.) Fermat has implementations for both BCMath and
> > ext-decimal, while also using GMP. It is much more difficult to control the
> > number of accurate digits in ext-decimal than in BCMath, but ext-decimal is
> > literally hundreds of times faster. I think, however, that Rudi (the author
> > of ext-decimal) was against including ext-decimal in core.
> >
>
> it isn't really needed if not at the language level.
>
> scaled basic operations can be (relatively) easily optimized, with an order
> of magnitude faster than what bcmath does.
>
> however, the real challenge, imho, is the different uses. That's where rock
> solid implementation like mpfr could help, for non basic ops or modes.
>
>
>
> > But if you want an alternate implementation for arbitrary precision
> > decimals, it is certainly the place that someone should start.
> >
>
> for the few areas I needed it, I made my own with add/sub and mul/div with
> intrinsics.  very little amount of codes and stable.
>
> I am not completely sure how to cover the different usages, scaled
> operations may be a good start and keeping bc math user land compatibility
> may not too hard.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Can we deprecate socket_set_blocking() ?

[Hans Henrik Bergan]

The only thing socket_set_blocking() is good for is to confuse people
looking for socket_set_block()

Re: [PHP-DEV] trim support for multibyte spaces

[Hans Henrik Bergan]

add a
void str_dump(const size_t strlen, const char *str)
{
printf("string(%zu) \"", strlen);
fwrite(str, strlen, 1, stdout);
printf("\"\n");
}

then replace the string_view stuff with

size_t teststrlen = strlen(teststr);
str_dump(teststrlen, teststr);
mb_trim(, , trim_lengths_num, trim_lengths, trim_chars);
str_dump(teststrlen, teststr);

and it should be pure C, i think

On Mon, 2 Oct 2023 at 15:36, youkidearitai  wrote:
>
> Hi, Hans.
>
> Thank you very much for your code. And sorry for late.
> I confirmed works fine.
> https://gist.github.com/youkidearitai/0018dee27353c00aebaff3bf57c5b8c6
>
> However, this code is C++17, php-src is C code.
> If you would like contribute, I would like written to C code.
>
> Regards
> Yuya
>
> 2023年10月1日(日) 19:46 Hans Henrik Bergan :
> >
> > .. probably a bunch of stuff that *could* be optimized or done better,
> > but one i saw just now is that instead of 2x nested loops and goto,
> > the outer loop and labels could be removed and the `goto
> > remove_from_start_continue_2;` could be replaced with `i=-1;` eg
> >
> > size_t local_strlen = *strlen;
> > char *local_str = *str;
> > for (size_t i = 0; i < trim_lengths_num; ++i)
> > {
> > if (local_strlen >= trim_lengths[i] && memcmp(local_str,
> > trim_chars[i], trim_lengths[i]) == 0)
> > {
> > local_strlen -= trim_lengths[i];
> > local_str += trim_lengths[i];
> > i = -1;
> > }
> > }
> >
> > 2x nested loops reduced to 1 loop, and goto removed~
> >
> > On Sun, 1 Oct 2023 at 10:43, Hans Henrik Bergan  
> > wrote:
> > >
> > > > If have any idea, feel free to comment to me.
> > >
> > > i think the C code would look something like
> > >
> > >
> > > void mb_trim(size_t *strlen, char **str, const size_t
> > > trim_lengths_num, const size_t *trim_lengths, const char **trim_chars)
> > > {
> > > size_t local_strlen = *strlen;
> > > char *local_str = *str;
> > > for (;;)
> > > {
> > > for (size_t i = 0; i < trim_lengths_num; ++i)
> > > {
> > > if (local_strlen >= trim_lengths[i] && memcmp(local_str,
> > > trim_chars[i], trim_lengths[i]) == 0)
> > > {
> > > local_strlen -= trim_lengths[i];
> > > local_str += trim_lengths[i];
> > > goto remove_from_start_continue_2;
> > > }
> > > }
> > > break;
> > > remove_from_start_continue_2:;
> > > }
> > > for (;;)
> > > {
> > > for (size_t i = 0; i < trim_lengths_num; ++i)
> > > {
> > > if (local_strlen >= trim_lengths[i] && memcmp(((local_str
> > > + local_strlen) - trim_lengths[i]), trim_chars[i], trim_lengths[i]) ==
> > > 0)
> > > {
> > > local_strlen -= trim_lengths[i];
> > > goto remove_from_end_continue_2;
> > > }
> > > }
> > > break;
> > > remove_from_end_continue_2:;
> > > }
> > > memmove(*str, local_str, local_strlen);
> > > char *newstr = (char *)realloc(*str, local_strlen);
> > > if (newstr != nullptr)
> > > {
> > > *strlen = local_strlen;
> > > *str = newstr;
> > > }
> > > else
> > > {
> > > // some error handling
> > > }
> > > }
> > >
> > > with my simple testcode looking like
> > >
> > > int main()
> > > {
> > > const char *trim_chars[] = {
> > > " ",
> > > "!",
> > > // utf8 whitespace:
> > > "\xE2\x80\x80", // EN QUAD
> > > "\xE2\x80\x81", // EM QUAD
> > > "\xE2\x80\x82", // EN SPACE
> > > "\xE2\x80\x83", // EM SPACE
> > > "\xE2\x80\x84", // THREE-PER-EM SPACE
> > > "\xE2\x80\x85", // FOUR-PER-EM SPACE
> > > "\xE2\x80\x86", // SIX-PER-EM SPACE
> > > };
> > > size_t trim_lengths[] = {
> > > strlen(trim_chars[0]),
> > > strlen(trim_chars[1]),
> > > strlen(trim

Re: [PHP-DEV] trim support for multibyte spaces

[Hans Henrik Bergan]

.. probably a bunch of stuff that *could* be optimized or done better,
but one i saw just now is that instead of 2x nested loops and goto,
the outer loop and labels could be removed and the `goto
remove_from_start_continue_2;` could be replaced with `i=-1;` eg

size_t local_strlen = *strlen;
char *local_str = *str;
for (size_t i = 0; i < trim_lengths_num; ++i)
{
if (local_strlen >= trim_lengths[i] && memcmp(local_str,
trim_chars[i], trim_lengths[i]) == 0)
{
local_strlen -= trim_lengths[i];
local_str += trim_lengths[i];
i = -1;
}
}

2x nested loops reduced to 1 loop, and goto removed~

On Sun, 1 Oct 2023 at 10:43, Hans Henrik Bergan  wrote:
>
> > If have any idea, feel free to comment to me.
>
> i think the C code would look something like
>
>
> void mb_trim(size_t *strlen, char **str, const size_t
> trim_lengths_num, const size_t *trim_lengths, const char **trim_chars)
> {
> size_t local_strlen = *strlen;
> char *local_str = *str;
> for (;;)
> {
> for (size_t i = 0; i < trim_lengths_num; ++i)
> {
> if (local_strlen >= trim_lengths[i] && memcmp(local_str,
> trim_chars[i], trim_lengths[i]) == 0)
> {
> local_strlen -= trim_lengths[i];
> local_str += trim_lengths[i];
> goto remove_from_start_continue_2;
> }
> }
> break;
> remove_from_start_continue_2:;
> }
> for (;;)
> {
> for (size_t i = 0; i < trim_lengths_num; ++i)
> {
> if (local_strlen >= trim_lengths[i] && memcmp(((local_str
> + local_strlen) - trim_lengths[i]), trim_chars[i], trim_lengths[i]) ==
> 0)
> {
> local_strlen -= trim_lengths[i];
> goto remove_from_end_continue_2;
> }
> }
> break;
> remove_from_end_continue_2:;
> }
> memmove(*str, local_str, local_strlen);
> char *newstr = (char *)realloc(*str, local_strlen);
> if (newstr != nullptr)
> {
> *strlen = local_strlen;
> *str = newstr;
> }
> else
> {
> // some error handling
> }
> }
>
> with my simple testcode looking like
>
> int main()
> {
> const char *trim_chars[] = {
> " ",
> "!",
> // utf8 whitespace:
> "\xE2\x80\x80", // EN QUAD
> "\xE2\x80\x81", // EM QUAD
> "\xE2\x80\x82", // EN SPACE
> "\xE2\x80\x83", // EM SPACE
> "\xE2\x80\x84", // THREE-PER-EM SPACE
> "\xE2\x80\x85", // FOUR-PER-EM SPACE
> "\xE2\x80\x86", // SIX-PER-EM SPACE
> };
> size_t trim_lengths[] = {
> strlen(trim_chars[0]),
> strlen(trim_chars[1]),
> strlen(trim_chars[2]),
> strlen(trim_chars[3]),
> strlen(trim_chars[4]),
> strlen(trim_chars[5]),
> strlen(trim_chars[6]),
> strlen(trim_chars[7]),
> strlen(trim_chars[8]),
> };
> size_t trim_lengths_num = sizeof(trim_lengths) / sizeof(trim_lengths[0]);
> char *teststr = strdup("  !  \xE2\x80\x80\xE2\x80\x81\xE2\x80\x82
>  Hello World !  \xE2\x80\x83\xE2\x80\x84\xE2\x80\x85\xE2\x80\x86  !
> ");
> // char *teststr = strdup("  !Hello World !!  ");
> size_t teststrlen = strlen(teststr);
> std::cout << teststrlen << ": \"" << std::string_view(teststr,
> teststrlen) << "\"" << std::endl;
> mb_trim(, , trim_lengths_num, trim_lengths, 
> trim_chars);
> std::cout << teststrlen << ": \"" << std::string_view(teststr,
> teststrlen) << "\"" << std::endl;
> return 0;
> }
>
>
> On Sat, 30 Sept 2023 at 13:16, youkidearitai  wrote:
> >
> > 2023年9月30日(土) 17:42 Saki Takamachi :
> > >
> > > > I also want to trim function of multibyte trim functions.
> > >
> > > > I think that in addition to mb_trim,
> > > mb_ltrim and mb_rtrim are also necessary.
> > >
> > > Hi.
> > >
> > > Having a new option besides regex sounds like a good idea for me, as a 
> > > user of a language that benefits from `mb_trim()`.
> > >
> > > Perhaps users are more intuitive about the usefulness of those functions 
> > > who have spent more time cleaning "multibyte spaces".
> >
> > Hi
> >
> > Thanks for reply.
> > I'm trying implements to trim for multibyte function.
> > Please give me some time.
> >
> > If have any idea, feel free to comment to me.
> >
> > Regards
> > Yuya
> >
> > --
> > ---
> > Yuya Hamada (tekimen)
> > - https://tekitoh-memdhoi.info
> > - https://github.com/youkidearitai
> > -
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] trim support for multibyte spaces

[Hans Henrik Bergan]

> If have any idea, feel free to comment to me.

i think the C code would look something like


void mb_trim(size_t *strlen, char **str, const size_t
trim_lengths_num, const size_t *trim_lengths, const char **trim_chars)
{
size_t local_strlen = *strlen;
char *local_str = *str;
for (;;)
{
for (size_t i = 0; i < trim_lengths_num; ++i)
{
if (local_strlen >= trim_lengths[i] && memcmp(local_str,
trim_chars[i], trim_lengths[i]) == 0)
{
local_strlen -= trim_lengths[i];
local_str += trim_lengths[i];
goto remove_from_start_continue_2;
}
}
break;
remove_from_start_continue_2:;
}
for (;;)
{
for (size_t i = 0; i < trim_lengths_num; ++i)
{
if (local_strlen >= trim_lengths[i] && memcmp(((local_str
+ local_strlen) - trim_lengths[i]), trim_chars[i], trim_lengths[i]) ==
0)
{
local_strlen -= trim_lengths[i];
goto remove_from_end_continue_2;
}
}
break;
remove_from_end_continue_2:;
}
memmove(*str, local_str, local_strlen);
char *newstr = (char *)realloc(*str, local_strlen);
if (newstr != nullptr)
{
*strlen = local_strlen;
*str = newstr;
}
else
{
// some error handling
}
}

with my simple testcode looking like

int main()
{
const char *trim_chars[] = {
" ",
"!",
// utf8 whitespace:
"\xE2\x80\x80", // EN QUAD
"\xE2\x80\x81", // EM QUAD
"\xE2\x80\x82", // EN SPACE
"\xE2\x80\x83", // EM SPACE
"\xE2\x80\x84", // THREE-PER-EM SPACE
"\xE2\x80\x85", // FOUR-PER-EM SPACE
"\xE2\x80\x86", // SIX-PER-EM SPACE
};
size_t trim_lengths[] = {
strlen(trim_chars[0]),
strlen(trim_chars[1]),
strlen(trim_chars[2]),
strlen(trim_chars[3]),
strlen(trim_chars[4]),
strlen(trim_chars[5]),
strlen(trim_chars[6]),
strlen(trim_chars[7]),
strlen(trim_chars[8]),
};
size_t trim_lengths_num = sizeof(trim_lengths) / sizeof(trim_lengths[0]);
char *teststr = strdup("  !  \xE2\x80\x80\xE2\x80\x81\xE2\x80\x82
 Hello World !  \xE2\x80\x83\xE2\x80\x84\xE2\x80\x85\xE2\x80\x86  !
");
// char *teststr = strdup("  !Hello World !!  ");
size_t teststrlen = strlen(teststr);
std::cout << teststrlen << ": \"" << std::string_view(teststr,
teststrlen) << "\"" << std::endl;
mb_trim(, , trim_lengths_num, trim_lengths, trim_chars);
std::cout << teststrlen << ": \"" << std::string_view(teststr,
teststrlen) << "\"" << std::endl;
return 0;
}


On Sat, 30 Sept 2023 at 13:16, youkidearitai  wrote:
>
> 2023年9月30日(土) 17:42 Saki Takamachi :
> >
> > > I also want to trim function of multibyte trim functions.
> >
> > > I think that in addition to mb_trim,
> > mb_ltrim and mb_rtrim are also necessary.
> >
> > Hi.
> >
> > Having a new option besides regex sounds like a good idea for me, as a user 
> > of a language that benefits from `mb_trim()`.
> >
> > Perhaps users are more intuitive about the usefulness of those functions 
> > who have spent more time cleaning "multibyte spaces".
>
> Hi
>
> Thanks for reply.
> I'm trying implements to trim for multibyte function.
> Please give me some time.
>
> If have any idea, feel free to comment to me.
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Security Audit Priorities

[Hans Henrik Bergan]

the php-fpm master<->php-fpm worker glue code. php-fpm master usually
runs as *root*, so a compromise in that glue could lead to webserver
rooting

On Mon, 25 Sept 2023 at 10:49, Derick Rethans  wrote:
>
> Hi,
>
> The Foundation is organising an external audit/security check of the PHP
> source code. As part of that, we would like to identify the places in
> the PHP source code where checking this will have the most impact.
>
> Typical areas would be where user input can be (automatically read) remotely, 
> such as
> our RFC 1867 HTTP header parser. But we are sure there are other
> important areas as well, and we would like your input.
>
> So, if you can suggest an area where doing an external review would have
> high impact, please reply to this email.
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
>
> Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
> Host of PHP Internals News: https://phpinternals.news
>
> mastodon: @derickr@phpc.social @xdebug@phpc.social
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Hans Henrik Bergan]

I think the submodule approach is fine, but maybe it should be moved from
Dmitry's gh to php-src gh, or maybe it's own dedicated group, to reduce the
bus factor (how much work needs to be done if Dmitry is hit by a bus~)

On Sat, Sep 16, 2023, 00:22 Tim Düsterhus  wrote:

> Hi
>
> On 9/15/23 17:50, Ben Ramsey wrote:
> > Additionally, despite the use of a Git submodule complicating things for
> > "everyone else," it provides a clear dependency and development
> > boundary, avoiding situations where the php-src version of IR drifts
> > from the upstream version. I think we can adjust tooling and messaging
> > to help folks know how to use the submodule. :-)
>
> Do not want: If the submodule repository goes away for whatever reason,
> the dependency will no longer be available. IR is currently sitting in
> Dmitry's personal GitHub account and it would not be the first time that
> a GitHub account is suspended for good or less good reasons [1].
>
> Bundle IR in some dedicated directory with php-src. Then updating it is
> as easy as "throw away the directory and copy over the new files". We
> could even automate that using GitHub actions to sync in the changes
> every night or so.
>
> Dmitry also said that he gave 'git subtree' a try. I don't know that
> command myself, but it looks exactly like what is required here. I would
> be interested in hearing why it didn't work well.
>
> Best regards
> Tim Düsterhus
>
> [1] Such as sanctions, see:
> https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC: Increasing the default BCrypt cost

[Hans Henrik Bergan]

>you're also measuring the startup cost of PHP itself.

yup correct

>A simple microtime(true) benchmark loop as used with my test script should be 
>fine for ballpark estimates

agreed

>dwarfing the measurement overhead.

wouldn't count out random cpu context switch/background noise
completely, see my hyperfine benchmark for cost 13:
>  Range (min … max):   717.3 ms … 754.5 ms10 runs
- over 10 runs, the fastest was 717ms and the slowest was 754ms, so
background noise made at least 37ms difference there.. but yeah
anyway, here's from your script:

hanshenrik@jonathan-dayton:~$ time php bench.php
Cost 8: 2.022854 total (0.020229 per hash)
Cost 9: 4.176210 total (0.041762 per hash)
Cost 10: 8.121596 total (0.081216 per hash)
Cost 11: 16.919405 total (0.169194 per hash)
Cost 12: 33.059071 total (0.330591 per hash)
Cost 13: 66.761731 total (0.667617 per hash)
Cost 14: 140.695820 total (1.406958 per hash)

real4m31.854s
user4m13.115s
sys 0m2.168s
hanshenrik@jonathan-dayton:~$ cat /proc/cpuinfo | head
(...)
model name  : AMD Opteron(tm) Processor 4122

On Tue, 12 Sept 2023 at 18:01, Tim Düsterhus  wrote:
>
> Hi
>
> On 9/12/23 17:56, Hans Henrik Bergan wrote:
> >> web hosters *love* their ancient hardware
> >
> > No kidding. dreamhost.com host over 1.5 million websites, presumably most
> > are on their "Shared Unlimited" package, which runs on
> > AMD Opteron 4122, a high-end server CPU from 2010.
> > Some benchmarks there:
>
> It appears your benchmarks are broken, because you're also measuring the
> startup cost of PHP itself. You should see an approximate doubling in
> time taken for each increase of the cost, but you have 122ms for 9 and
> 166ms for 10.
>
> A simple microtime(true) benchmark loop as used with my test script
> should be fine for ballpark estimates, as password_hash() is pretty
> heavy, dwarfing the measurement overhead.
>
> Best regards
> Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Increasing the default BCrypt cost

[Hans Henrik Bergan]

>web hosters *love* their ancient hardware

No kidding. dreamhost.com host over 1.5 million websites, presumably most
are on their "Shared Unlimited" package, which runs on
AMD Opteron 4122, a high-end server CPU from 2010.
Some benchmarks there:

hanshenrik@jonathan-dayton:~$ cat /proc/cpuinfo | head
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 8
model name  : AMD Opteron(tm) Processor 4122
stepping: 0
microcode   : 0x1da
cpu MHz : 2200.000
cache size  : 512 KB
physical id : 0
hanshenrik@jonathan-dayton:~$ php -v
PHP 8.2.5 (cli) (built: Apr 13 2023 18:45:57) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.5, Copyright (c) Zend Technologies
with Zend OPcache v8.2.5, Copyright (c), by Zend Technologies
hanshenrik@jonathan-dayton:~$ hyperfine 'php -r
'\''password_hash("password1234",PASSWORD_BCRYPT,["cost"=>9]);'\'''
Benchmark 1: php -r
'password_hash("password1234",PASSWORD_BCRYPT,["cost"=>9]);'
  Time (mean ± σ): 122.7 ms ±   2.4 ms[User: 78.1 ms, System: 33.7
ms]
  Range (min … max):   120.0 ms … 127.5 ms22 runs

hanshenrik@jonathan-dayton:~$ hyperfine 'php -r
'\''password_hash("password1234",PASSWORD_BCRYPT,["cost"=>10]);'\'''
Benchmark 1: php -r
'password_hash("password1234",PASSWORD_BCRYPT,["cost"=>10]);'
  Time (mean ± σ): 166.4 ms ±   2.7 ms[User: 115.1 ms, System: 39.3
ms]
  Range (min … max):   163.0 ms … 171.2 ms18 runs

hanshenrik@jonathan-dayton:~$ hyperfine 'php -r
'\''password_hash("password1234",PASSWORD_BCRYPT,["cost"=>11]);'\'''
Benchmark 1: php -r
'password_hash("password1234",PASSWORD_BCRYPT,["cost"=>11]);'
  Time (mean ± σ): 246.0 ms ±   5.2 ms[User: 198.2 ms, System: 34.5
ms]
  Range (min … max):   241.0 ms … 256.5 ms12 runs

hanshenrik@jonathan-dayton:~$ hyperfine 'php -r
'\''password_hash("password1234",PASSWORD_BCRYPT,["cost"=>12]);'\'''
Benchmark 1: php -r
'password_hash("password1234",PASSWORD_BCRYPT,["cost"=>12]);'
  Time (mean ± σ): 409.7 ms ±   3.6 ms[User: 355.6 ms, System: 41.6
ms]
  Range (min … max):   405.3 ms … 416.6 ms10 runs

hanshenrik@jonathan-dayton:~$ hyperfine 'php -r
'\''password_hash("password1234",PASSWORD_BCRYPT,["cost"=>13]);'\'''
Benchmark 1: php -r
'password_hash("password1234",PASSWORD_BCRYPT,["cost"=>13]);'
  Time (mean ± σ): 729.3 ms ±  10.6 ms[User: 672.5 ms, System: 43.8
ms]
  Range (min … max):   717.3 ms … 754.5 ms10 runs

must say, surprisingly good performance for a 2010 cpu

On Sun, Sep 10, 2023, 18:06 Tim Düsterhus  wrote:

> Hi
>
> On 9/8/23 18:49, Alexandru Pătrănescu wrote:
> >> in response to the recent "PASSWORD_DEFAULT value" thread [1], I've
> >> created an RFC to discuss an increase of the default BCrypt costs for
> >> `password_hash()` from the current value of 10.
> >>
> >> https://wiki.php.net/rfc/bcrypt_cost_2023
> >>
> >>
> >
> > I think 12 looks reasonable.
> > I've performed some tests myself on private hosted servers with
> > newer hardware with good results for 12 around 0.1 seconds.
>
> wow, that is a 33% reduction even compared to the Xeon E-2246G and thus
> hard to believe. What CPU is that?
>
> > Can this be integrated into PHP 8.3, as it's not a new feature that can
> > cause problems?
>
> The release managers for PHP 8.3 would need to decide that. However I'd
> rather not include this in PHP 8.3 at this point.
>
> > Pushing it to 8.4 will delay the real usage with 2-3 more years already.
>
> IMO this is fine. Common frameworks can and do already use a different
> default. Symfony apparently is at 13 by default. Laravel uses 10, but
> I've already pinged someone on Mastodon to maybe have a look at the
> results of this RFC:
>
> https://phpc.social/@timwolla/111025125667858110
>
> The current default of 10 is not insecure and rolling this out a little
> more slowly will mean that more and more of the old and slow hardware
> will be retired and replaced by modern hardware, lessening the impact.
>
> > I feel like the hardware performance improvements (specifically single
> > thread performance) slightly increased in the past 3-4 years, and soon
> most
> > of the hosting providers will be using it.
> >
>
>  From my experience as a developer of a software that is commonly run on
> shared hosting, web hosters *love* their ancient hardware, because it's
> fully depreciated from a taxation / accounting PoV and every extra day
> it is used is "free money". Customers commonly are not able to tell they
> are running with tens of other customers on this ancient hardware and
> thus won't complain ("loading times of 1 second are fine").
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC: Increasing the default BCrypt cost

[Hans Henrik Bergan]

@Craig warning, it's very random what kind of CPU performance you get
on your t2 instances, the CPUs vary greatly from modern to many years
old.

I know of Fortune 500 companies that have automated systems to spin up
t2 instances until they randomly get "a good one", then discard the
others, because the cpu performance vary so widely


On Thu, 7 Sept 2023 at 23:38, Craig Francis  wrote:
>
> On 7 Sep 2023, at 18:26, Tim Düsterhus  wrote:
> > in response to the recent "PASSWORD_DEFAULT value" thread [1], I've created 
> > an RFC to discuss an increase of the default BCrypt costs for 
> > `password_hash()` from the current value of 10.
> >
> > https://wiki.php.net/rfc/bcrypt_cost_2023
>
>
> Thanks Tim,
>
> Just quickly running this on two AWS EC2 servers, to give rough figures for a 
> VM (note usual issues like noisy neighbours, turbo-boost, thermal throttling, 
> etc).
>
> t2.nano
>
> Cost 8: 2.083060 total (0.020831 per hash)
> Cost 9: 4.115596 total (0.041156 per hash)
> Cost 10: 8.238419 total (0.082384 per hash)
> Cost 11: 16.334089 total (0.163341 per hash)
> Cost 12: 32.693785 total (0.326938 per hash)
> Cost 13: 65.587982 total (0.655880 per hash)
> Cost 14: 131.358058 total (1.313581 per hash)
>
> t2.small
>
> Cost 8: 2.062625 total (0.020626 per hash)
> Cost 9: 4.142067 total (0.041421 per hash)
> Cost 10: 8.231646 total (0.082316 per hash)
> Cost 11: 16.851889 total (0.168519 per hash)
> Cost 12: 32.814440 total (0.328144 per hash)
> Cost 13: 69.409889 total (0.694099 per hash)
> Cost 14: 133.682196 total (1.336822 per hash)
>
> Both nano and small only have 1 vCPU, have 0.5 vs 1 GiB RAM, and a different 
> number of CPU Credits/hr.
>
> We recently discussed hashing and costs at one of our OWASP meetings, we came 
> to conclusion that the default of 10 for bcrypt probably should be increased, 
> but only to 11 for typical websites. The main concern was about making 
> denial-of-service attacks easier (think of a normal website developer, who 
> won't limit the number of login attempts).
>
> It's also worth keeping in mind the difference between online vs offline 
> attacks, what it's being used for, human behaviour when it comes to choosing 
> bad passwords ("123456" and "Password1!" will still be guessed very quickly), 
> etc.
>
> Craig
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PASSWORD_DEFAULT value

[Hans Henrik Bergan]

Argon2 is opt-in, not opt-out, at compile-time, so then we would have to
agree on it being acceptable for PASSWORD_DEFAULT to have different values
depending on compile-time options, maybe thats completely fine, or maybe it
isn't, idk.

But as Dusterhus points out, Argon2 is inferior to bcrypt anyway, according
to people much smarter than myself.

Oh and Argon2 has been around since 2015 and multiple vulnerabilities have
been discovered, speeding up brute force/dictionary attacks. Can't say the
same for bcrypt

On Wed, Sep 6, 2023, 18:52 Tim Düsterhus  wrote:

> Hi
>
> On 9/6/23 18:08, Vinicius Dias wrote:
> > I was wondering here... Is there any reason for `PASSWORD_DEFAULT`'s
> > value not to be `PASSWORD_ARGON2ID`?
> >
>
> To the best of my knowledge Argon2 is not available in a "default"
> installation of PHP without including any external dependencies.
>
> Also Argon2 for settings that are reasonable for interactive
> authentication is worse than BCrypt according to:
>
> https://twitter.com/TerahashCorp/status/1155119064248913920
> and
> https://twitter.com/TerahashCorp/status/1155129705034653698
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Apply strict_types to internal functions

[Hans Henrik Bergan]

* I think most code actually using strict_types=1 is built with the
assumption that internal functions use strict too, so it's entirely
possible that the backwards-compatibility issue is so small that we
can get away with internal functions just inheriting the userland
strict_types

On Tue, 29 Aug 2023 at 18:36, Hans Henrik Bergan  wrote:
>
> maybe we could do a
> declare(internal_strict_types=1);
> on a per-file basis just like the existing userland strict_types?
> (name is up for bikeshedding ofc)
>
> On Tue, 29 Aug 2023 at 17:49, Claude Pache  wrote:
> >
> >
> >
> > > Le 29 août 2023 à 15:19, Saki Takamachi  a écrit :
> > >
> > >> Hi,
> > >>
> > >> The larger issue is that higher-order functions do not inherit the 
> > >> `strict_types` mode from its calling code, and this is not specific to 
> > >> internal functions.
> > >>
> > >> If you intend to change that for internal functions (with proper 
> > >> deprecation period, of course), you might consider making such a 
> > >> behaviour also possible for userland functions (probably using some 
> > >> opt-in); so that future higher-order internal functions do not become 
> > >> impossible to polyfill.
> > >>
> > >> —Claude
> > >
> > > Hi, thank you for confirming.
> > >
> > > If you simply put the problem you pointed out in the code, would it be 
> > > something like this?
> > > https://gist.github.com/SakiTakamachi/8292dbfe92a2029a6c7b506b12296b7d
> > >
> > > Admittedly, I don't think this is intuitive either.
> >
> > That might not be intuitive to you, but it follows directly from the 
> > specified semantics: whether a function is called in `strict_types` mode or 
> > not, depends only on where the function is called. I personally doubt that 
> > there is an easy way to adjust the rule in order to make it both 
> > “intuitive” and simple.
> >
> > >
> > > [...]
> > >
> > > When considering the inheritance of strict_types, I think that it should 
> > > be an attribute that can be set in “php.ini" instead of being specified 
> > > for each file.
> > >
> > > What do you think?
> >
> > Beware that there are many third-party packages that have not opted for 
> > `strict_types=1`; if you enable that mode globally, you might make those 
> > packages malfunction.
> >
> > As I have just checked, among the packages I’ve installed via composer, 
> > there are more packages that do not use `strict_types=1`, than packages 
> > that use it. Among those that don’t use `strict_types`, the following ones 
> > are fairly common:
> >
> > google/apiclient
> > league/oauth2-client
> > michelf/php-markdown
> > microsoft/microsoft-graph
> > phpmailer/phpmailer
> > phpoffice/phpspreadsheet
> > phpseclib/phpseclib
> >
> > —Claude
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Apply strict_types to internal functions

[Hans Henrik Bergan]

maybe we could do a
declare(internal_strict_types=1);
on a per-file basis just like the existing userland strict_types?
(name is up for bikeshedding ofc)

On Tue, 29 Aug 2023 at 17:49, Claude Pache  wrote:
>
>
>
> > Le 29 août 2023 à 15:19, Saki Takamachi  a écrit :
> >
> >> Hi,
> >>
> >> The larger issue is that higher-order functions do not inherit the 
> >> `strict_types` mode from its calling code, and this is not specific to 
> >> internal functions.
> >>
> >> If you intend to change that for internal functions (with proper 
> >> deprecation period, of course), you might consider making such a behaviour 
> >> also possible for userland functions (probably using some opt-in); so that 
> >> future higher-order internal functions do not become impossible to 
> >> polyfill.
> >>
> >> —Claude
> >
> > Hi, thank you for confirming.
> >
> > If you simply put the problem you pointed out in the code, would it be 
> > something like this?
> > https://gist.github.com/SakiTakamachi/8292dbfe92a2029a6c7b506b12296b7d
> >
> > Admittedly, I don't think this is intuitive either.
>
> That might not be intuitive to you, but it follows directly from the 
> specified semantics: whether a function is called in `strict_types` mode or 
> not, depends only on where the function is called. I personally doubt that 
> there is an easy way to adjust the rule in order to make it both “intuitive” 
> and simple.
>
> >
> > [...]
> >
> > When considering the inheritance of strict_types, I think that it should be 
> > an attribute that can be set in “php.ini" instead of being specified for 
> > each file.
> >
> > What do you think?
>
> Beware that there are many third-party packages that have not opted for 
> `strict_types=1`; if you enable that mode globally, you might make those 
> packages malfunction.
>
> As I have just checked, among the packages I’ve installed via composer, there 
> are more packages that do not use `strict_types=1`, than packages that use 
> it. Among those that don’t use `strict_types`, the following ones are fairly 
> common:
>
> google/apiclient
> league/oauth2-client
> michelf/php-markdown
> microsoft/microsoft-graph
> phpmailer/phpmailer
> phpoffice/phpspreadsheet
> phpseclib/phpseclib
>
> —Claude
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests

[Hans Henrik Bergan]

how are errors handled, like if the format of php://input is
unrecognized, not valid multipart/form-data and not valid
application/x-www-form-urlencoded?
errors? exceptions? nothing?

On Tue, 20 Jun 2023 at 11:26, Ilija Tovilo  wrote:
>
> Hi internals
>
> A while ago I encountered a limitation of how RFC1867 requests are
> handled in PHP. PHP populates the $_POST and $_FILES superglobals when
> the Content-Type is multipart/form-data or
> application/x-www-form-urlencoded, but only when the method is POST.
> For application/x-www-form-urlencoded PUT requests this is not a
> problem because the format is simple, usually limited in size and PHP
> offers functions to parse it, namely parse_str and parse_url. For
> RFC1867 it's a different story.
>
> The code handling the request will need to use streams because RFC1867
> is often used with files, the format is much more complicated, files
> should be cleaned up when the request ends if unused, etc. Handling
> this manually is non-trivial. This has been reported many years ago,
> and evidently caused a bit of frustration.
> https://bugs.php.net/bug.php?id=55815
>
> This is not limited to PUT either, multipart/form-data bodies are
> valid with other requests. Here's the approach I believe is best.
>
> Introduce a new function (currently named populate_post_data()) to
> read the input stream and populate the $_POST and $_FILES
> superglobals. The function works for any non-POST requests. It assumes
> that none of the input stream has been consumed, and that the
> Content-Type is set accordingly. A nice side-effect of this approach
> is that it may be used with the enable_post_data_reading ini setting
> to decide whether to parse the RFC1867 bodies dynamically. For
> example, a specific endpoint may accept bigger requests. The function
> may be implemented in a more generic way 1. by returning the
> data/files arrays instead of populating the superglobals and 2. by
> providing an input stream manually. I don't know if there's such a
> use-case and thus if this is worthwhile, as it would require bigger
> changes in the RFC1867 handling.
>
> Here's the proof-of-concept implementation:
> https://github.com/php/php-src/pull/11472
>
> For completeness, here are other options I considered.
>
> 1. Create a new $_PUT superglobal that is always populated. Two
> issues: The obvious one is that this is limited to PUT requests. While
> we could also introduce $_PATCH, this seems like a poor solution.
> While discouraged, other methods can also contain bodies. Another
> issue is that the code for processing RFC1867 consumes the input
> stream. This constitutes a BC break. Buffering the input is not
> feasible for large requests that would be expected here.
> 2. The same as option 1, but populate the existing $_POST global. This
> comes with the same BC break.
> 3. The same as options 1 or 2 with an additional ini setting to opt
> into the behavior. The issue with this approach is that both the old
> and new behavior might be desired in different parts of the same
> application. The ini option can't be changed at runtime because the
> populating of the superglobals happens before user code is being
> executed.
>
> Let me know what your thoughts are. If there is consensus in the
> feedback I'll update the implementation accordingly and post an update
> to the list. If there is no consensus, I will create an RFC.
>
> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: make FILE_ constants not collide with LOCK_

[Hans Henrik Bergan]

thanks for the thumbs up and morrisonlevi's review, it's appreciated.
still needs a maintainer/core-dev approval though.

btw the old file() flags check was actually flawed and would miss some
incorrect flags, for example `flags = 10` aka `flags=  (1 << 1) | (1
<< 3)` is, and always was, incorrect for file() because file() does
not support PHP_FILE_APPEND, but the old flags error-check code would
miss it (and miss the error in file("file", FILE_APPEND) ). the new
check doesn't. As an added bonus, seems the new flags check is about
7% faster too: https://quick-bench.com/q/j3k_unXcE91gVdTRH9Dm0nxpDUA
(guess it's because it avoids the `flags < 0` thing)

On Tue, 6 Jun 2023 at 12:54, Hans Henrik Bergan  wrote:
>
> Can I get some attention to https://github.com/php/php-src/pull/11254
> ? It's been 3 weeks and nothing so far

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] make FILE_ constants not collide with LOCK_

[Hans Henrik Bergan]

Can I get some attention to https://github.com/php/php-src/pull/11254
? It's been 3 weeks and nothing so far

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

[Hans Henrik Bergan]

DATE_ISO8601 doesn't have to be removed anytime soon, but no new code
should be written using that constant, thus an E_DEPRECATED is
warranted.

Is anyone really arguing against that statement?

On Tue, 30 May 2023 at 18:26, Hans Henrik Bergan  wrote:
>
> >In my opinion, deprecating this does not do anything besides annoying
> users.
>
> In my opinion, since it isn't, and likely never was, a legal ISO8601
> string, it's a no-brainer that it should be deprecated. (it's at least
> been illegal since iso8601:2004 released in 2004)
>
> On Fri, 26 May 2023 at 12:17, Derick Rethans  wrote:
> >
> > On Fri, 19 May 2023, Jorg Sowa wrote:
> >
> > > I would like to propose the deprecation of the constants DATE_ISO8601,
> > > DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231.
> >
> > …
> >
> > > In my opinion the question is not whether this constant should be
> > > deprecated, but when. I know that the problem was discussed in the past,
> > > but I hope enough time has passed already to touch this topic again
> > > although of the BC nature. [6] 
> > > <https://externals.io/message/113657#114885>
> > > [7]
> >
> > In my opinion, deprecating this does not do anything besides annoying
> > users.
> >
> > > <https://www.reddit.com/r/PHP/comments/hnd438/why_isnt_date_iso8601_deprecated/>
> > > Arguments for deprecating DATE_RFC7231:
> > > - error prone nature, the format never really supported timezone. I'm not
> > > sure how it appeared in the code, but tests clearly lack cases for this
> > > format. I'm not sure if it was missed on purpose, but with tests it would
> > > be obvious that the format shouldn't ever appear in the core. [8]
> > > <https://www.php.net/manual/en/class.datetimeinterface.php> [9]
> > > <https://github.com/php/doc-en/pull/2296>
> >
> > This should instead be fixed of being deprecated. It is a recent
> > addition after all.
> >
> > cheers,
> > Derick
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions

[Hans Henrik Bergan]

sounds like array_find could be implemented by just adding a new flag
for array_filter's $mode:
ARRAY_FILTER_STOP_ON_FIRST_MATCH
or some such?

On Fri, 2 Jun 2023 at 02:15, Casper Langemeijer  wrote:
>
> On Thu, Jun 1, 2023, at 18:02, Janusz Szczypka wrote:
> > array_find(): This function would allow developers to find the first 
> > element in
> > an array that satisfies a specific condition. The condition would be 
> > defined by a callback function.
>
> This would actually be an alternative to a simple foreach() with an if() and 
> a break. As your example implementation makes clear.
>
> array_find() and array_find_key() would still do the same internally, but add 
> a function call adding the overhead of pushing parameters to stack, switching 
> the scope, passing return value back switch scope and pop from the callstack 
> again. If parameters or return value are typed this adds even more overhead.
>
> I don't think there is any optimisation possible when this is done in C.
>
> To the proposer it probably feels that this is an array function currently 
> missing, but instead it's probably better not to have array_find() because 
> people might actually use it for larger datasets.
>
> Although I acknowledge that it will reduce the number of lines of PHP code it 
> doesn't actually reduce the mental capacity to read and maintain code. I find 
> the simple elemental building blocks of loops, conditionals and expressions 
> easier and more expressive. In my experience this is especially so for less 
> experienced developers.
>
> Then there is a problem of naming. array_search() and array_find(). To a new 
> developer, how would they know which is which?
>
> Also there is the missing array_find_value_and_key() method. Because why 
> should we be limited to either matching the key OR the value?
>
> Greetings, Casper
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

[Hans Henrik Bergan]

>In my opinion, deprecating this does not do anything besides annoying
users.

In my opinion, since it isn't, and likely never was, a legal ISO8601
string, it's a no-brainer that it should be deprecated. (it's at least
been illegal since iso8601:2004 released in 2004)

On Fri, 26 May 2023 at 12:17, Derick Rethans  wrote:
>
> On Fri, 19 May 2023, Jorg Sowa wrote:
>
> > I would like to propose the deprecation of the constants DATE_ISO8601,
> > DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231.
>
> …
>
> > In my opinion the question is not whether this constant should be
> > deprecated, but when. I know that the problem was discussed in the past,
> > but I hope enough time has passed already to touch this topic again
> > although of the BC nature. [6] 
> > [7]
>
> In my opinion, deprecating this does not do anything besides annoying
> users.
>
> > 
> > Arguments for deprecating DATE_RFC7231:
> > - error prone nature, the format never really supported timezone. I'm not
> > sure how it appeared in the code, but tests clearly lack cases for this
> > format. I'm not sure if it was missed on purpose, but with tests it would
> > be obvious that the format shouldn't ever appear in the core. [8]
> >  [9]
> > 
>
> This should instead be fixed of being deprecated. It is a recent
> addition after all.
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] mb_ucfirst and mb_lcfirst

[Hans Henrik Bergan]

I think it would be useful.
For some reason, lots of people on stackoverflow has a hard time
implementing this function in userland:
on 
https://stackoverflow.com/questions/2517947/ucfirst-function-for-multibyte-character-encodings
there are 10 broken implementations of mb_ucfirst, and 1 correct one
(disclaimer: I only consider my own implementation correct:
https://stackoverflow.com/a/58915632/1067003
and consider every other implementation on the list broken in one way
or another. and i was really surprised that nobody else got it right.)

On Sat, 27 May 2023 at 23:11, Niels Dossche  wrote:
>
> Hey internals
>
> I recently saw a comment on Reddit about the lack of a multibyte version of 
> ucfirst and lcfirst.
> I was surprised to see this is indeed the case.
> I also checked the modes of mb_convert_case: the closest supported one is 
> title case, but there's no mode for only handling the first letter.
>
> I have two questions (and some sub-questions):
> Does anyone know if there is a historical reason for this? A quick search on 
> externals.io didn't provide something useful.
> Do you think this is useful? If yes, do you think this should be part of 
> mb_convert_case or should this be a standalone function?
>
> Kind regards
> Niels
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

[Hans Henrik Bergan]

>outdated format, standard has been changed while ago

What do you mean? Do you mean that the constant was legal at some point?
Was there ever a version of ISO8601 allowing the mixing of "extended
format" and "basic format" ? The earliest version I've read, iso8604:2004,
does not allow it (more on that here:
https://externals.io/email/114883/source - can't find the proper link right
now, am on phone). Haven't read the older 1988/1999/2000 versions, and it's
possible one of those allowed it, but I doubt it. The only thing I can say
for sure is that it's been illegal since the 2004 version

On Fri, May 19, 2023, 23:17 Jorg Sowa  wrote:

> > How common is it in the wild?  I am pretty sure I've used it myself
> without really thinking many times, which I suspect is common.  Knowing how
> much code would be impacted would determine how we'd go about deprecating
> it and on what timeline.
>
> I'm not sure how would be possible to find out. I suppose most of the
> frameworks (and thus popular PHP libraries) avoid this constant as showed
> in Drupal and Carbon. The scanning of popular libraries will not show the
> scale of the problem (however I will do it tomorrow) Helpful fact is that
> those constants are just constants so it's easily replaceable with
> strings 'Y-m-d\\TH:i:sO'
> and 'D, d M Y H:i:s \\G\\M\\T'.
>

Re: [PHP-DEV] Please remove the Sicherheitsüberprüfung Security captcha from php.net

[Hans Henrik Bergan]

>a misconfiguration

That's my guess too.
I Hope the server configuration people get the message.

>I think the page is just hard-coded in German and English

I'm not sure there is an English version at all - I'm not accessing it
from a german IP address (a Norwegain one - actually multiple
Norwegian ones), and my Accept-Language doesn't mention German, and it
specifically requests English, and I'm not accessing the german
de.php.net, so if an English version existed, there would be no reason
for it to give me a German version, so my best guess is that it's just
hardcoded in German.
(tl;dr: if an English version exists, I have no idea why I was served
the German version.)

On Sun, 14 May 2023 at 23:36, Rowan Tommins  wrote:
>
> On 14 May 2023 21:48:51 BST, Hans Henrik Bergan  wrote:
> >fwiw for those of you lucky enough to not get the captcha page, it
> >looks like https://i.imgur.com/l9YbIz5.png
>
> I'd never seen it before, but saw it just now when looking for mirror 
> information. My guess is that either there's a misconfiguration somewhere 
> making it far too sensitive, or there's something like a DoS attack being 
> defended against.
>
>
> >Also I'm not sure why it's in German
>
> I think the page is just hard-coded in German and English because the company 
> hosting the mirror ("MyraCloud") are based in Germany, and haven't added any 
> other translations.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Please remove the Sicherheitsüberprüfung Security captcha from php.net

[Hans Henrik Bergan]

multiple times per week now, i get this Security
Sicherheitsüberprüfung captcha page when visiting php.net and it's
really annoying to solve that captcha multiple times per week.
"PHP is that annoying language where you have to solve captchas just
to read the documentation"
is not the experience we want to give users, and as ChatGPT puts it

>>lead to negative perceptions of PHP as a language, as well as decreased 
>>productivity among developers who would have to spend extra time overcoming 
>>the verification obstacles to access the documentation. It would also make it 
>>more difficult for new developers to learn PHP, which could ultimately have a 
>>negative impact on the growth and adoption of the language

fwiw for those of you lucky enough to not get the captcha page, it
looks like https://i.imgur.com/l9YbIz5.png
Also I'm not sure why its in German - i dont speak German, and my
Accept-Lanaguage header says
Accept-Language: en-US,en;q=0.9,nb;q=0.8,no;q=0.7,vi;q=0.6

(where en-US is English, and nb is Norwegian Bokmål, and no is
Norwegain, and vi is Vietnamese. German isn't even on the
accept-language list!)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving a tmpfile()?

[Hans Henrik Bergan]

@Robert I know windows has problems with moving files that are opened
by other processes,
BUT this still works fine on Windows 10 running on NTFS:

rename returns true and the file really is moved (and the file is no
longer automatically deleted - i suspect PHP's tmpfile() try to delete
the original path on cleanup, and don't keep track of renames/movings)


On Sat, 29 Apr 2023 at 14:56, Robert Landers  wrote:
>
> On Sat, Apr 29, 2023 at 9:33 AM Dan Liebner  wrote:
> >
> > Are there any inherent problems with moving a file created with tmpfile()?
> > In practice, it seems that it can be done and the file will not be deleted
> > after being moved and the file handle closed.
> >
> > Thanks,
> > Dan
>
> I suspect it depends on the OS. For example, in Linux, you can delete
> a file you are writing to without issues, but you cannot in Windows.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Future stability of PHP?

[Hans Henrik Bergan]

several PHP versions will be maintained for 10 years by third-party vendors.
PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com
maintains PHP5.6 with multiple customers paying 6000€/year for 5.6
maintenance.
Canonical intends to maintain PHP7.0 until April 2026 for their Ubuntu
Pro 16.04.
Canonical intends to maintain PHP7.2 until April 2028 for their Ubuntu
Pro 18.04.
Canonical intends to maintain PHP7.4 until April 2030 for their Ubuntu
Pro 20.04.
Canonical intends to maintain PHP8.1 until April 2032 for their Ubuntu
Pro 22.04.

Red Hat does something similar for their RHEL customers. ~~

On Mon, 10 Apr 2023 at 20:30, Deleu  wrote:
>
> On Mon, Apr 10, 2023, 1:17 PM Pierre Joye  wrote:
>
> > hello,
> >
> >
> > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller 
> > wrote:
> >
> > > Hello,
> > >
> > > I'm sorry if this isn't the correct mailing list for that discussion but
> > I
> > > couldn't find a more appropriate one where people actually know how the
> > > wind is
> > > blowing.
> > >
> > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of
> > > deprecations and fatal errors spooked me a bit (details below if you're
> > > interested). That got me wondering about the long-term stability of PHP
> > > (as in
> > > language and API breaks) and I looked at the RFCs. I got the impression
> > > that
> > > static typing has a lot of traction now and I have no idea of what the
> > > fallout
> > > might be of changing a dynamically typed language into a statically
> > > typed one.
> >
> >
> > I keep reading this in multiple languages, pr even more frameworks.
> >
> > I understand agency work, managers pushing new features instead of a
> > cleaning some legacy.
> >
> > however years of ignoring deprecation notices (very few were introduced
> > right before 8.0).
> >
> > Most of them could have been fixed within a couple of hours in any code
> > base, if they had tests.
> >
> > I would suggest, very very nicely, to review and rethink the development
> > flows of these projects instead of asking php to freeze.
> >
> > best,
> > Pierre
> >
>
> I resent the sentiment of "if your code or development process was exactly
> like mine you wouldn't be here complaining" and I believe nobody is asking
> PHP to freeze. Not everyone has the ability to fix every deprecation within
> a couple of hours and not everyone has tests. Yes, we get it, it's common
> knowledge nowadays that code without test is unmanageable, but if you
> inherited a 15 year old codebase developed by multiple developers in a
> start-up mentality producing code faster than they could actually plan for
> and with no tests, its going to take some time to clean that up and if I
> take longer than you would, does it mean I matter less as a PHP user?
>
> PHP 8 is pretty great to work with and a lot better than previous versions,
> but there was no opt-in aspect to a lot of PHP breakages. All that we're
> asking here is for a bit more forgiveness to existing code that was
> developed 2 decades ago by a complete different generation and still need
> to run today while we clean it up.
>
> >

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Can we get compile time routines?

[Hans Henrik Bergan]

Something like
```
$data = compile_time_routine(function() {
return json_decode(file_get_contents("large.json"), true);
});
```
being equivalent at runtime to
```
$data = array(...whatever json_decode returned...);
```
and
```
echo "opcache compiled at " . compile_time_routine(function(){return
date(DateTime::RFC3339);});
```
being equivalent at runtime to
```
echo "opcache compiled at " . "2023-03-16T09:43:00+01:00";
```

- at my work there are jsons which is being fetched/parsed like
```
$data=json_decode(file_get_contents("large.json"), true);
```
several times per second, while it would be fine for them to only be
fetched/parsed every time opcache is reset.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC karma request

[Hans Henrik Bergan]

Good point, and come to think of it, people wishing to $offset can fseek()
before before fpassthru() anyway. Nevermind the $offset thing, it's more
trouble than it's worth ^^

On Sun, Feb 12, 2023, 15:46 Thomas Hruska  wrote:

> On 2/12/2023 5:47 AM, Hans Henrik Bergan wrote:
> > Fwiw I would also find an $offset argument useful. fpassthru's lack of
> both
> > $length and $offset made my life harder when implementing "HTTP 206
> Partial
> > Content" / "HTTP range requests",
>
> I was going to suggest this myself until I realized that an $offset
> parameter would be rather problematic.  What happens if the offset is
> negative?  Does a negative offset mean seek backwards from the current
> position OR start at that many bytes from the end of the stream?  Is the
> offset a seek operation or a read operation?  Not all streams are
> seekable and reading is generally a fairly slow, blocking I/O operation.
>   Also, not all stream lengths are known.  A negative offset in
> non-seekable scenarios would almost certainly have to throw an error.
> fseek()/fread() are more flexible and consistent for getting to the
> desired starting point in a source stream.
>
> A negative $length would also present some issues.  Again, not all
> stream lengths are known.  Correctly handling negative values would
> require managing an internally, temporarily allocated buffer of
> sufficient size to be able to backtrack streams of unknown length.  And
> might even have to cache the entire stream in RAM, which would be
> problematic for 1GB+ streams.  Or just throw an error for such streams.
> Or just restrict $length to non-negative values only.
>
> In short, a non-negative, nullable $length parameter is the only
> well-defined operation for fpassthru().
>
> fpassthru() is largely a convenience wrapper around fread()/unbuffered
> echo in a loop with some extra output buffer management and is subject
> to PHP max_execution_time.  For large files and/or slow/high latency
> networks, PHP can timeout before delivering all content.
>
> There are several web server extensions available (X-Sendfile and
> X-Accel-Redirect) where, for local files, the rest of the request can be
> handed off from PHP to the web server to completely avoid writing any
> file output to the output buffer and also avoid timeout issues.  The
> existence of modern web server extensions for all major web servers
> limits the overall usefulness of fpassthru().  IMO, $length should be
> added for language-level completeness/convenience but it might also be a
> good idea to mention X-Sendfile/X-Accel-Redirect in the documentation
> for fpassthru() so that users are encouraged to leverage
> resource-efficient technologies wherever possible.
>
>
> > Ended up with a
> > $output = fopen('php://output', 'wb'); + stream_copy_to_stream()
> > hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
> > the way)
> >
> >
> > On Sat, Feb 11, 2023, 15:26 Niels Dossche 
> wrote:
> >
> >> Dear internals
> >>
> >> I would like to gain RFC karma for creating and proposing an RFC:
> >> "Implement GH-9673: $length argument for fpassthru".
> >> Account name: nielsdos
> >>
> >> Thanks in advance
> >> Kind regards
> >> Niels
>
>
> --
> Thomas Hruska
> CubicleSoft President
>
> CubicleSoft has over 80 original open source projects and counting.
> Plus a couple of commercial/retail products.
>
> What software are you looking to build?
>
>

Re: [PHP-DEV] RFC karma request

[Hans Henrik Bergan]

Fwiw I would also find an $offset argument useful. fpassthru's lack of both
$length and $offset made my life harder when implementing "HTTP 206 Partial
Content" / "HTTP range requests",

Ended up with a
$output = fopen('php://output', 'wb'); + stream_copy_to_stream()
hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
the way)


On Sat, Feb 11, 2023, 15:26 Niels Dossche  wrote:

> Dear internals
>
>
> I would like to gain RFC karma for creating and proposing an RFC:
> "Implement GH-9673: $length argument for fpassthru".
> Account name: nielsdos
>
>
> Thanks in advance
> Kind regards
> Niels
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Hans Henrik Bergan]

function f(int $value){
$value="foo"; // should this be a TypeError? BC break all the things
}

On Mon, 6 Feb 2023 at 22:15, someniatko  wrote:
>
> Hi there,
>
> I am not a core PHP language developer, just a regular PHP programmer, and
> cannot speak for the whole community, so I'll just share my opinion.
>
> I believe a new language feature suggestion should contain not only its
> description, but also motivation: i.e. what are we trying to achieve with
> it. Will the development experience be worse without it, or maybe it
> disallows some sneaky bugs to appear in your code, or maybe it acts as a
> native documentation for your code etc.
>
> Personally it's hard for me to see what kind of improvement will
> restricting a type of a variable bring. It may prevent repurposing the
> variable with the same name for a different use somewhere down the
> function, which can lead to bugs if a function is large enough. However,
> for such cases I think better idea would be to introduce `const` variables
> like in JavaScript - which can only be set once and cannot be reassigned
> later. This way you'll also guarantee the type of the variable will be
> preserved.
>
> > We can add types in a lot of places, but we still don't have a way to add
> types to inline variables.
>
> > int $value = 10;
> > $value = 'foo'; // TypeError
>
> Can you describe some use cases where this feature will be useful? I see
> it's coming from statically typed / compiled languages like C++, but in
> such languages compiler must know variable type in order to manage memory
> properly. As PHP is an interpreted  language, it doesn't have this problem.
>
> Regards,
> Illia / someniatko

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.1 and OpenSSL

[Hans Henrik Bergan]

+1, we don't want to bundle and maintain and monkey-patch 1.1.1
ourselves for 14.4 months,
which I guess would be the alternative.

On Wed, 18 Jan 2023 at 13:20, Christoph M. Becker  wrote:
>
> Hi all!
>
> While the official builds for PHP 8.2 already use OpenSSL 3.0, the PHP
> 8.1 builds are still using OpenSSL 1.1.1.  However, OpenSSL 1.1.1 is
> only supported till 2023-09-11[1], while PHP 8.1 is supported till
> 2024-11-25[2].  Although I don't like bumping the OpenSSL version in the
> middle of PHP 8.1's lifetime, I suppose it is necessary to avoid falling
> behind security support.  And if we do that bump, we better do it sooner
> than later.
>
> So, if there are no unforeseen problems, I suggest to build PHP
> 8.1.16RC1 with OpenSSL 3.0 (PHP 8.1.15RC1 has already been built with
> OpenSSL 1.1.1).
>
> Thoughts?  Objections?
>
> [1] 
> [2] 
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] base64url format

[Hans Henrik Bergan]

how about base64_encode(string $string, int $flags = 0): string
with $flags accepting BASE64_RFC4648 and BASE64_NO_PADDING
or something to that effect?

On Mon, 9 Jan 2023 at 22:56, David Gebler  wrote:
>
> On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans 
> wrote:
>
> > On 9 January 2023 18:49:28 GMT, Sara Golemon  wrote:
> > >I've been working with JWTs lately and that means working with Base64URL
> > >format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
> > >This is essentially the same thing as normal Base64, but instead of '+'
> > and
> > >'/', it uses '-' and '_', respectively. It also allows leaving off the
> > >training '=' padding characters.
> > >
> > >So far, I've just been including polyfills like this:
> > >
> > >function base64url_decode(string $str): string {
> > >return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
> > >(strlen($str) % 4)) % 4, '='));
> > >}
> > >
> > >function base64_encode(string $str): string {
> > >return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
> > >}
> > >
> > >These work fine, but they create a LOT of string copies along the way
> > which
> > >shouldn't be necessary.
> > >Would anyone mind if skipped RFC and just added `base64url_encode()` and
> > >`base64url_decode()` to PHP 8.3?
> >
> > Should these be new functions, or options to base64_encode instead? I'd
> > guess base64_decode could just accept both?
>
>
> I think from a UX/DX perspective, separate functions would be my
> preference, base64_url_encode and base64_url_decode (extra underscore which
> I feel is more consistent with PHP stock library). One consideration though
> is that base64_urlencode or base64_url_encode are function names which are
> likely already defined by a number of userland projects or libraries, since
> it's a very common thing to do with the prevalence of JWTs, so if the RFC
> process is being bypassed in this case, a new optional parameter to
> base64_encode might be better. But I think it would be weird to have
> base64_encode(bool $urlEncode = false) or something, which is presumably
> what it would look like.
>
> Dare I float the suggestion of a Base64 class, making base64_encode and
> base64_decode functions aliases for Base64::encode() and Base64::decode()
> respectively, then new Base64::urlEncode() and urlDecode() methods?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] base64url format

[Hans Henrik Bergan]

when http_build_query() wanted to support different encoding schemes,
PHP_QUERY_RFC1738 and PHP_QUERY_RFC3986 was made, instead of creating
http_build_query_rfc1738() and http_build_query_rfc3986() , hmm

On Mon, 9 Jan 2023 at 21:12, Tim Düsterhus  wrote:
>
> Hi
>
> On 1/9/23 19:49, Sara Golemon wrote:
> > I've been working with JWTs lately and that means working with Base64URL
> > format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
> > This is essentially the same thing as normal Base64, but instead of '+' and
> > '/', it uses '-' and '_', respectively. It also allows leaving off the
> > training '=' padding characters.
> >
>
> With JWTs you likely also want a constant time encoder that is not
> susceptible for cache-timing leaks [1]. For this reason
> https://github.com/paragonie/constant_time_encoding is a most-have
> dependency for my projects and I generally use the functions of that
> library by default, unless there is a reason not to (high performance
> required). That library also includes a b32 implementation that cmb wished.
>
> There's also
> https://www.php.net/manual/en/function.sodium-bin2base64.php which is
> constant-time and supports b64url, unfortunately it's not guaranteed to
> be available.
>
> Best regards
> Tim Düsterhus
>
> [1] It's likely more important for encrypted tokens, than only for
> signed ones.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] What to do with opaque GMP objects which allows instantiation

[Hans Henrik Bergan]

Why isn't that generating an ArgumentCountError?

On Fri, Dec 30, 2022, 21:36 Tim Düsterhus  wrote:

> Hi
>
> On 12/30/22 18:36, G. P. B. wrote:
> >   - Add a proper constructor that does the same as gmp_init() in
> master/8.2.1
>
> My preference would be this (without any target branch preference):
>
> If there is no technical reason to disallow creating new GMP objects via
> 'new', then I believe that making those objects behave more like
> "regular" / "userland" objects is a good thing.
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] ext-random: add random_float() ?

[Hans Henrik Bergan]

btw while we're on the topic, does anyone know if this function gives
biased results/is-safe or not? i honestly don't know:
function random_float(float $min, float $max): float
{
if ($min > $max) throw new \InvalidArgumentException("min must be
less than max");
if ($min === $max) return $min;
return $min + random_int(0, PHP_INT_MAX) / PHP_INT_MAX * ($max - $min);
}


On Tue, 20 Dec 2022 at 09:06, Hans Henrik Bergan  wrote:
>
> >returns a value between 0.0 and 1.0.
>
> wouldn't it be better to follow random_int(int $min, int $max) design? eg
> random_float(float $min, float $max): float
>
> On Tue, 20 Dec 2022 at 07:27, Go Kudo  wrote:
> >
> > Hi Internals.
> >
> > Congratulations on the release of PHP 8.2.
> > I just recently upgraded production PHP from 7.4 to 8.1 :)
> >
> > Now that my work is done, I was thinking about a proposal for a sunsetting
> > of existing functions for PHP 8.3 based on the features introduced in
> > ext-random, and I realized that there is no alternative to `lcg_value()`.
> >
> > Essentially, this could be completely replaced by
> > Random\Randomizer::getFloat(), but there are easier `random_int()` and
> > `random_bytes()` functions for ints and strings.
> >
> > The Randomizer may be overkill and complicated for PHP use cases where
> > random number reproducibility is not required in many cases.
> >
> > So, why not add a `random_float(): float` function? This function, like the
> > others, uses CSPRNG and returns a value between 0.0 and 1.0. This behavior
> > is `Closed` `Closed`.
> >
> > Opinions are welcome.
> >
> > Regards,
> > Go Kudo

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] ext-random: add random_float() ?

[Hans Henrik Bergan]

>returns a value between 0.0 and 1.0.

wouldn't it be better to follow random_int(int $min, int $max) design? eg
random_float(float $min, float $max): float

On Tue, 20 Dec 2022 at 07:27, Go Kudo  wrote:
>
> Hi Internals.
>
> Congratulations on the release of PHP 8.2.
> I just recently upgraded production PHP from 7.4 to 8.1 :)
>
> Now that my work is done, I was thinking about a proposal for a sunsetting
> of existing functions for PHP 8.3 based on the features introduced in
> ext-random, and I realized that there is no alternative to `lcg_value()`.
>
> Essentially, this could be completely replaced by
> Random\Randomizer::getFloat(), but there are easier `random_int()` and
> `random_bytes()` functions for ints and strings.
>
> The Randomizer may be overkill and complicated for PHP use cases where
> random number reproducibility is not required in many cases.
>
> So, why not add a `random_float(): float` function? This function, like the
> others, uses CSPRNG and returns a value between 0.0 and 1.0. This behavior
> is `Closed` `Closed`.
>
> Opinions are welcome.
>
> Regards,
> Go Kudo

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Experimental features

[Hans Henrik Bergan]

sounds like that's been done with PECL previously yeah?
PECL json until native json_encode in PHP5.2.0,
PECL PDO until native PDO in PHP 5.1.0,
PECL ZendOpcache until native opcache in PHP 5.5.5
etc?

On Wed, 5 Oct 2022 at 00:38, Flávio Heleno  wrote:
>
> On Tue, Oct 4, 2022, 17:43 David Rodrigues  wrote:
>
> > I wanted to suggest the possibility of introducing experimental features to
> > PHP.
> >
> > This is an old thread I guess, but I think it's good to reevaluate the
> > situation from time to time, as other languages already do this to some
> > extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
> > libraries (React) bring features natively in an experimental way.
> >
> > I wanted to propose that we bring this idea into PHP, so we wouldn't have
> > to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out these
> > new features, and so when these versions arrive, they'll already be quite
> > polished, avoiding patches sometime later due to wider usage of users.
> >
> > My idea is to have two levels of experimental features:
> >
> > (1) Via declare(), when the feature affects how PHP can act when reading
> > the file itself. Eg. declare(experimental_operator_override =
> > true), Something that happens with Kotlin, for example, when we use some
> > experimental annotations like contracts. These declarations work "per
> > file", so whenever it is necessary to use it, it must be declared.
> >
> > (2) Via experimental identifier name. Eg. experimental_json_validate() or
> > Experimental::json_validate(), like in Kotlin and also in React.
> >
> > Experimental features can only be brought into a minor version (eg. PHP
> > 8.1.12) when it is minimally refined and practically ready to use. It would
> > be "kind of" an expected final version, no new patches are expected (we
> > hope), unless something really went unnoticed.
> >
> > Despite this, experimental features may not exist until the next
> > major/minor release if its practical inefficiency is found or if the
> > concept is shown to be invalid. So it should always be a "use with care".
> >
> > However, if an experimental feature is successful, it becomes final at the
> > next major/minor or major/minor+1. The experimental version becomes an
> > alias during some future versions until it is removed entirely. This is the
> > time for users to adapt their code and for IDEs to help us find them.
> >
> > With this, we can understand whether users are making use of a certain
> > feature or not, make improvements on it, etc.
> >
> > I notice that many good features are rejected because they are believed to
> > be bad for PHP or can be confusing, but without any practical testing.
> > Experimental features can make this analysis more grounded in practical
> > data than just possibilities.
> >
> > However, this also doesn't mean that any idea can become an experimental
> > feature, but ideas that have a good foundation and a good discussion before
> > it. The difference is that the feature can be tested in practice before
> > being totally rejected, and approved features can be delivered ahead of
> > time to refine before the next version is released, allowing users to try
> > them out more easily.
> >
> >
> > Atenciosamente,
> > David Rodrigues
> >
>
> Hi David,
>
> Could this be done through extensions instead of having to develop a new
> process/support code?
>
> When json support was first introduced into php, it was done as an
> extension and then, after a while, incorporated into the core.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Sanitize filters

[Hans Henrik Bergan]

FILTER_SANITIZE_EMAIL should burn. If you have a bad email address, i can't
imagine the correct solution is to remove characters until it becomes
valid, short of a trim()

On Sun, Oct 2, 2022, 17:10 Larry Garfield  wrote:

> On Sat, Oct 1, 2022, at 10:39 AM, Kamil Tekiela wrote:
> > Hi Internals,
> >
> > For quite some time now, PHP's sanitize filters have "Rustled My
> Jimmies".
> > These filters bother me because I can't really justify their existence. I
> > can understand that a few of them are sensible and may come in handy,
> but I
> > would like to talk about some of these in particular.
> >
> > In PHP 8.1, we have deprecated FILTER_SANITIZE_STRING which I deemed to
> be
> > a priority due to its confusing name and behaviour. The rest is slightly
> > less dangerous, but as was pointed out to me in a recent conversation
> with
> > a PHP developer, these filters are all very confusing.
> >
> > I would like to have some opinions on the following filters. What do you
> > think we should do with them? Deprecate? Fix? Provide better
> documentation?
> >
> > ---
> >
> > *FILTER_SANITIZE_ENCODED *- "URL-encode string, optionally strip or
> encode
> > special characters."
> > Now, what does that mean? PHP has two functions for URL encoding:
> urlencode
> > used for encoding query-string parts, and rawurlencode used for encoding
> > any other URL part (two different RFCs are followed by these functions).
> > Which of these RFCs is applied in this filter? Furthermore, the
> description
> > says that "special characters" can be stripped or encoded. Is one of
> these
> > actions the default and the other can be selected by a flag or are both
> > optional? What are these special characters? Are they special in the
> > context of URL? If so, why did we encode them first? If these are HTML
> > special characters (there's no single definition of special HTML chars),
> > then why does this filter encode them if the filter is for URL
> > sanitization? What does backtick have to do with any of this
> > (FILTER_FLAG_STRIP_BACKTICK)?
> >
> > *FILTER_SANITIZE_ADD_SLASHES - "*Apply addslashes(). (Available as of PHP
> > 7.3.0)"
> > This filter was added as a replacement for magic_quotes filter. According
> > to PHP documentation, addslashes is supposed to be used when injecting
> PHP
> > variables into eval'd string. Real-life showed that this function is used
> > in a lot of places that have nothing to do with PHP's eval. I am not sure
> > if the sanitize filter is misused in a similar fashion, but judging from
> > the fact that it was meant as a replacement for magic_quotes, my guess is
> > that it's very likely still abused.
> >
> > *FILTER_SANITIZE_EMAIL *- "Remove all characters except letters, digits
> and
> > !#$%&'*+-=?^_`{|}~@.[]."
> > Which RFC does this adhere to? It strips slashes and quoted parts,
> doesn't
> > allow IPv6 addresses and doesn't accept RFC 6530 email addresses. This
> > filter is ok for simple usage, but it isn't true to any known
> specification
> > AFAIK.
> >
> > *FILTER_SANITIZE_SPECIAL_CHARS *- "HTML-encode '"<>& and characters with
> > ASCII value less than 32, optionally strip or encode other special
> > characters."
> > What's the intended purpose of this filter? "Special characters" are
> still
> > not clearly defined, but at least it's more clear than
> > the FILTER_SANITIZE_ENCODED description. Same question about backticks
> > though: why? Why encode ASCII <32 chars?
> >
> > *FILTER_SANITIZE_FULL_SPECIAL_CHARS *- "Equivalent to calling
> > htmlspecialchars() with ENT_QUOTES set. Encoding quotes can be disabled
> by
> > setting FILTER_FLAG_NO_ENCODE_QUOTES. Like htmlspecialchars(), this
> filter
> > is aware of the default_charset and if a sequence of bytes is detected
> that
> > makes up an invalid character in the current character set then the
> entire
> > string is rejected resulting in a 0-length string. When using this filter
> > as a default filter, see the warning below about setting the default
> flags
> > to 0."
> > Not to be mistaken with FILTER_SANITIZE_SPECIAL_CHARS. As long as it's
> not
> > used with filter_input(), it's the least problematic. We
> > have htmlspecialchars() though, so how useful is this filter?
> >
> > *FILTER_UNSAFE_RAW *- What makes it unsafe? Why isn't this just
> > called FILTER_RAW_STRING? If the value being filtered is something other
> > than a string, what will this filter return? Integers, floats, booleans
> and
> > nulls are converted to a string, Arrays and objects make the filter fail.
> >
> > ---
> >
> > Let's quickly mention the filter flags.
> >
> > The FILTER_FLAG_STRIP_LOW flag will also remove tabs, carriage returns
> and
> > newlines as these are all less than 32 ASCII codes. When is this useful
> and
> > expected?
> >
> > The FILTER_FLAG_ENCODE_LOW flag "encodes" ASCII <32 codes presumably into
> > HTML entities, although that's not specified anywhere in the PHP manual.
> > The word HTML does not appear on the
> > 

Re: [PHP-DEV] Re: str_repeat performance

[Hans Henrik Bergan]

maybe you'll find
$t=microtime(true) - $startTime;
var_dump($t,number_format($t,10));

interesting, https://3v4l.org/Ejia3

On Sat, 10 Sept 2022 at 17:11, Eugene Sidelnyk  wrote:

> Oh, yes. Sorry for that.
>
> Thanks for pointing out.
>
> On Sat, Sep 10, 2022 at 3:23 PM Christoph M. Becker 
> wrote:
>
> > On 10.09.2022 at 14:19, Eugene Sidelnyk wrote:
> >
> > > I have noted some strange points about `str_repeat` performance. It
> looks
> > > like the lesser `$times` argument is, the bigger is execution time
> (only
> > if
> > > we consider big numbers).
> > >
> > > For example, `str_repeat('%d ', 12500);` is a lot slower than
> > > `str_repeat('%d ', 125)`.
> > >
> > > First case (slow one):
> > > https://3v4l.org/ZAoGi
> > >
> > > Second case (fast one):
> > > https://3v4l.org/YIdQM
> >
> > It seems you have misinterpreted the results.  4.792213439941406E-5 is
> > certainly much smaller than 0.013129949569702148, for instance.
> >
> > --
> > Christoph M. Becker
> >
> >
>

Re: [PHP-DEV] No longer allow block mode for declare(encoding)

[Hans Henrik Bergan]

>it might be hard to properly implement support

No effort should be wasted supporting this.
+1

On Wed, Aug 31, 2022, 21:21 Sara Golemon  wrote:

> On Wed, Aug 31, 2022 at 10:43 AM Christoph M. Becker 
> wrote:
>
> > recently, there was a bug report regarding declare(encoding)[1].  I've
> > checked that, and found that the current implementation of
> > declare(encoding) doesn't make sense regarding "block mode", since this
> > is completely ignored; instead, each (allowed) declare(encoding) works
> > from where it is written till the next declare(encoding) (well, probably
> > more or less).
> >
> > Since I consider switching the character encoding in the middle of a
> > file not reasonable (and it might be hard to properly implement support
> > for that), I suggest to disallow block mode for declare(encoding) as of
> > PHP 8.3.  A respective PR is available[2].
> >
> >
> I think I can imagine scenarios where switching encodings within a file
> would work?  Especially for ASCII transparent encodings...  That said,
> if you're currently depending on multiple encodings in a single file then
> you probably deserve whatever you get.
>
> +1
>
> -Sara
>

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Hans Henrik Bergan]

quote
> you can't efficiently validate JSON in userland

Has anyone actually put that claim to the test? Has anyone actually made a
userland json validator (not just wrap json_decode()/json_last_error()) for
performance comparison?
( if not, https://www.json.org/JSON_checker/JSON_checker.c  would probably
be a good start)

On Fri, 26 Aug 2022 at 11:00, Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi Dusk,
>
> pt., 26 sie 2022 o 08:17 Dusk  napisał(a):
>
> > On Aug 25, 2022, at 21:47, Michał Marcin Brzuchalski <
> > michal.brzuchal...@gmail.com> wrote:
> > > The same goes here and I'm not convinced we should introduce next small
> > function that can be simply implemented in user land.
> >
> > What "simple implementation in userland" do you have in mind? Can you
> > provide an example?
> >
> > json_decode() is not an acceptable substitute here -- as David Gebler has
> > observed, decoding a large JSON structure can have a significant impact
> on
> > memory usage, even if the data is immediately discarded. Any
> implementation
> > based on string processing, on the other hand, is likely to be
> dramatically
> > slower, and may have subtle differences in behavior from PHP's JSON
> parser.
>
>
> A `json_decode()` is a substitute that IMO solves 99% of use cases.
> If I'd follow your logic and accept every small addition that handles 1% of
> use cases, somebody will raise another RFC
> for simplexml_validate_string or yaml_validate and the next
> PhpToken::validate.
> All above can be valid if we trust that people normally validate 300MB
> payloads to do nothing if they DON'T fail and there is nothing strange
> about that.
>
> Cheers,
>

Re: [PHP-DEV] xoshiro** edge case (all zeros)

[Hans Henrik Bergan]

dangerous to be sure, but it's also a technically valid seed,
are you sure we should disallow a valid seed?

On Thu, 4 Aug 2022 at 20:33, Tim Düsterhus  wrote:

> Hi
>
> On 8/4/22 10:09, Anton Smirnov wrote:
> > xoshiro** has a known edge case: all-zero seed
>
> Indeed, good catch. I had that in mind, but forgot about it.
>
> >  >
> > $engine = new \Random\Engine\Xoshiro256StarStar(str_repeat("\0", 32));
> >
> > while (true) {
> >  echo hex2bin($engine->generate()), PHP_EOL; // 
> > }
> >
> > It should be documented and/or handled
> >
> > It's only for a string seed, int seed is not affected
> >
>
> I've created a PR here:
>
> https://github.com/php/php-src/pull/9250
>
> I've opted to throw a ValueError in that case, as that's the only safe
> option that does not introduce a bias.
>
> The 32xNUL seed basically should only happen for manually written
> testing input and not happen otherwise. An actual random seed will
> result in 32 NUL bytes with just a 2**-256 chance and when relying on
> the implicit CSPRNG seeding (`null` as seed parameter) my PR will just
> retry to catch even that edge case.
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Character range syntax ".." for character masks

[Hans Henrik Bergan]

>1. Are there any reasonable objections to consistently implementing
character range expressions for all character masks?

would be a minor BC break to silently change the meaning of memspn($str,
"a..b"), which currently has the same meaning as "a.b" with wasted cpu
cycles, but with your suggestion it would become the same meaning as "ab"
and the dot would no longer pass the check..
But then again, currently writing ".." is just a waste of cpu, and i don't
think i've actually ever seen anyone do that in the wild
¯\_(ツ)_/¯


On Fri, 29 Jul 2022 at 10:58, Guilliam Xavier 
wrote:

> On Fri, Jul 29, 2022 at 7:15 AM mickmackusa  wrote:
>
> >
> >
> > On Monday, July 25, 2022, Guilliam Xavier 
> > wrote:
> >
> >> On Sat, Jul 9, 2022 at 1:56 AM mickmackusa 
> wrote:
> >>
> >>> I've discovered that several native string functions offer a character
> >>> mask
> >>> as a parameter.
> >>>
> >>> I've laid out my observations at
> >>> https://stackoverflow.com/q/72865138/2943403
> >>>
> >>
> >> Out of curiosity, why do you say that strtr() is "not a good candidate
> >> because character order matters" (although you give a reasonable
> example)?
> >> Maybe you have some counter-example?
> >>
> >> Regards,
> >>
> >> --
> >> Guilliam Xavier
> >>
> >
> > I prefer to keep my scope very tight when posting on Stack Overflow.
> >
> > My focus was purely on enabling character range syntax for native
> > functions with character mask parameters.  My understanding of character
> > masks in PHP requires single-byte characters and no meaning to character
> > order.
> >
> > When strtr() is fed two strings, they cannot be considered "character
> > masks" because the character orders matter.
> >
> > If extending character range syntax to parameters which are not character
> > masks, I might support the feature for strtr(), but ensuring that the two
> > strings are balanced will be made more difficult with ranged syntax.
> > strtr() will silently condone imbalanced strings.
> https://3v4l.org/PY15F
> >
>
> Thanks for the clarifications. You're right that the internal
> `php_charmask` converts a character list (possibly containing one or more
> ranges) into a 256-char *mask*, thus "losing" any original order; so
> strtr() actually couldn't use the same implementation (even without
> ranges), and a counter-example is `strtr('adobe', 'abcde', 'ebcda')`
> (`strtr('adobe', 'a..e', 'e..a')` would trigger a Warning "Invalid
> '..'-range, '..'-range needs to be incrementing").
>
> I had seen a parallel with the Unix `tr` command, which *does* support
> [incrementing] ranges (e.g. both `echo adobe | tr abcde ABCDE` and `echo
> adobe | tr a-e A-E` give "ADoBE", while `echo adobe | tr abcde edcba` gives
> "eboda" but `echo adobe | tr a-e e-a` errors "range-endpoints of 'e-a' are
> in reverse collating sequence order"), but its implementation doesn't use
> character masks indeed (
> https://github.com/coreutils/coreutils/blob/master/src/tr.c), and `echo
> abracadabra | tr a-f x` gives "xxrxxrx" not "xbrxcxdxbrx"; and it also
> supports more things like POSIX character classes...
>
> PS: I find the `strtr(string $string, array $replace_pairs)` form generally
> superior to the `strtr(string $string, string $from, string $to)` one
> anyway ;)
>
> Regards,
>
> --
> Guilliam Xavier
>

Re: [PHP-DEV] Windows PECL build machine died

[Hans Henrik Bergan]

.. should have written "making the cpus run hotter and clock lower and
harming single-thread performance without significantly increasing total
throughput, sometimes even harming total throughput" - and making it harder
to see how much *actual* cpu is being used by a process (a process
seemingly using 50% of a physical core might actually be using near 100% of
a core, but you can't see it in htop because HT makes it look like
50%/the-ht-core-looks-ready-to-go-even-if-it-isn't) - comparatively AMD's
SMT seems to nearly always increase total throughput.

On Fri, 22 Jul 2022 at 23:56, Hans Henrik Bergan 
wrote:

> 10 days of radio silence? What's going on? anyway benchmarks (countsey of
> bench.sh ) of the server/bandwidth
>
>  A Bench.sh Script By Teddysun ---
>  Version: v2022-06-01
>  Usage  : wget -qO- bench.sh | bash
> --
>  CPU Model  : Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz
>  CPU Cores  : 40 @ 2524.597 MHz
>  CPU Cache  : 30720 KB
>  AES-NI : Enabled
>  VM-x/AMD-V : Enabled
>  Total Disk : 393.6 GB (48.7 GB Used)
>  Total Mem  : 125.9 GB (12.0 GB Used)
>  Total Swap : 8.0 GB (0 Used)
>  System uptime  : 10 days, 2 hour 11 min
>  Load average   : 40.18, 40.10, 40.13
>  OS : Ubuntu 20.04.4 LTS
>  Arch   : x86_64 (64 Bit)
>  Kernel : 5.4.0-122-generic
>  TCP CC : cubic
>  Virtualization : Dedicated
>  Organization   : AS31798 DataCity
>  Location   : Kitchener / CA
>  Region : Ontario
> --
>  I/O Speed(1st run) : 812 MB/s
>  I/O Speed(2nd run) : 841 MB/s
>  I/O Speed(3rd run) : 821 MB/s
>  I/O Speed(average) : 824.7 MB/s
> --
>  Node NameUpload Speed  Download Speed  Latency
>  Speedtest.net941.15 Mbps   829.87 Mbps 3.09 ms
>  Los Angeles, US  937.01 Mbps   903.15 Mbps 64.21 ms
>  Dallas, US   941.23 Mbps   898.69 Mbps 36.36 ms
>  Montreal, CA 888.80 Mbps   916.91 Mbps 11.09 ms
>  Paris, FR886.36 Mbps   820.77 Mbps 90.50 ms
>  Amsterdam, NL854.88 Mbps   770.73 Mbps 98.16 ms
>  Shanghai, CN 426.16 Mbps   833.23 Mbps 216.21 ms
>  Nanjing, CN  439.53 Mbps   542.91 Mbps 198.60 ms
>  Seoul, KR465.37 Mbps   367.20 Mbps 216.88 ms
>  Singapore, SG417.93 Mbps   132.76 Mbps 212.71 ms
>  Tokyo, JP668.62 Mbps   676.35 Mbps 134.48 ms
> --
>  Finished in: 5 min 35 sec
>  Timestamp  : 2022-07-22 21:35:37 UTC
> --
>
> - it incorrectly says 393GB because of partitioning, it's actually 1TB
>
> - I've intentionally disabled Hyperthreading because... in my
> opinion/experience, hyperthreading implementations in older Intel CPUs
> often did more harm than good, making the cpus run hotter and clock lower,
> this is a (high-end) 2011 model. (I have the opposite experience with AMD
> SMT fwiw)
>
>
>
> On Thu, 14 Jul 2022 at 01:18, Hans Henrik Bergan 
> wrote:
>
>> Fwiw Chris Haas / vendiadvertising.com has reached out, they're willing
>> to sponsor raid(1) if my proposal is accepted.
>> Haas is reading this mailing list, but does not wish to participate/post
>> directly at present.
>> (I have no prior relation, never heard of them before today)
>>
>> On Tue, 12 Jul 2022 at 22:31, Hans Henrik Bergan 
>> wrote:
>>
>>> i have a 40-core 128GB RAM server with 1 (and only 1) static ipv4
>>> address that I intend to keep around until at least 27 november 2025 (but
>>> unsure after that),
>>> it has more RAM/CPU than i need, and i could set up a virtual machine on
>>> it and give VNC access to the VM in the form of
>>> > ssh -L :localhost:3389 user@ip
>>> then point a RDP/VNC client to localhost:
>>> i can dedicate individual TCP ports to it, but not any of 22, 80, 443,
>>> 5900,  5901, 8083, , 587, 2525
>>> (after which i can recommend Teamviewer for a more comfortable access)
>>>
>>> but the server has several caveats:
>>> - it's un-raided, rolling just a single 1TB SSD, if that SSD was to die,
>>> everything on it would be lost, and it would probably take days to replace
>>

Re: [PHP-DEV] Windows PECL build machine died

[Hans Henrik Bergan]

10 days of radio silence? What's going on? anyway benchmarks (countsey of
bench.sh ) of the server/bandwidth

 A Bench.sh Script By Teddysun ---
 Version: v2022-06-01
 Usage  : wget -qO- bench.sh | bash
--
 CPU Model  : Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz
 CPU Cores  : 40 @ 2524.597 MHz
 CPU Cache  : 30720 KB
 AES-NI : Enabled
 VM-x/AMD-V : Enabled
 Total Disk : 393.6 GB (48.7 GB Used)
 Total Mem  : 125.9 GB (12.0 GB Used)
 Total Swap : 8.0 GB (0 Used)
 System uptime  : 10 days, 2 hour 11 min
 Load average   : 40.18, 40.10, 40.13
 OS : Ubuntu 20.04.4 LTS
 Arch   : x86_64 (64 Bit)
 Kernel : 5.4.0-122-generic
 TCP CC : cubic
 Virtualization : Dedicated
 Organization   : AS31798 DataCity
 Location   : Kitchener / CA
 Region : Ontario
--
 I/O Speed(1st run) : 812 MB/s
 I/O Speed(2nd run) : 841 MB/s
 I/O Speed(3rd run) : 821 MB/s
 I/O Speed(average) : 824.7 MB/s
--
 Node NameUpload Speed  Download Speed  Latency
 Speedtest.net941.15 Mbps   829.87 Mbps 3.09 ms
 Los Angeles, US  937.01 Mbps   903.15 Mbps 64.21 ms
 Dallas, US   941.23 Mbps   898.69 Mbps 36.36 ms
 Montreal, CA 888.80 Mbps   916.91 Mbps 11.09 ms
 Paris, FR886.36 Mbps   820.77 Mbps 90.50 ms
 Amsterdam, NL854.88 Mbps   770.73 Mbps 98.16 ms
 Shanghai, CN 426.16 Mbps   833.23 Mbps 216.21 ms
 Nanjing, CN  439.53 Mbps   542.91 Mbps 198.60 ms
 Seoul, KR465.37 Mbps   367.20 Mbps 216.88 ms
 Singapore, SG417.93 Mbps   132.76 Mbps 212.71 ms
 Tokyo, JP668.62 Mbps   676.35 Mbps 134.48 ms
--
 Finished in: 5 min 35 sec
 Timestamp  : 2022-07-22 21:35:37 UTC
--

- it incorrectly says 393GB because of partitioning, it's actually 1TB

- I've intentionally disabled Hyperthreading because... in my
opinion/experience, hyperthreading implementations in older Intel CPUs
often did more harm than good, making the cpus run hotter and clock lower,
this is a (high-end) 2011 model. (I have the opposite experience with AMD
SMT fwiw)



On Thu, 14 Jul 2022 at 01:18, Hans Henrik Bergan 
wrote:

> Fwiw Chris Haas / vendiadvertising.com has reached out, they're willing
> to sponsor raid(1) if my proposal is accepted.
> Haas is reading this mailing list, but does not wish to participate/post
> directly at present.
> (I have no prior relation, never heard of them before today)
>
> On Tue, 12 Jul 2022 at 22:31, Hans Henrik Bergan 
> wrote:
>
>> i have a 40-core 128GB RAM server with 1 (and only 1) static ipv4 address
>> that I intend to keep around until at least 27 november 2025 (but unsure
>> after that),
>> it has more RAM/CPU than i need, and i could set up a virtual machine on
>> it and give VNC access to the VM in the form of
>> > ssh -L :localhost:3389 user@ip
>> then point a RDP/VNC client to localhost:
>> i can dedicate individual TCP ports to it, but not any of 22, 80, 443,
>> 5900,  5901, 8083, , 587, 2525
>> (after which i can recommend Teamviewer for a more comfortable access)
>>
>> but the server has several caveats:
>> - it's un-raided, rolling just a single 1TB SSD, if that SSD was to die,
>> everything on it would be lost, and it would probably take days to replace
>> the drive.
>> - it's located in a somewhat unstable environment, occasional power
>> outage, it was out on 30 june, 23 june, 27 january, and in 2021 was down on
>> 30 august. (it boots up and recovers automatically, but it has a reboot
>> time of roughly 300 seconds until ssh responds again)
>> - I can not offer a dedicated IP (but can offer some dedicated ports)
>> - May be decommissioned after 27-11-2025
>>
>> If that sounds like a good idea, I'll want a ssh public key.
>>
>>
>> On Tue, 12 Jul 2022 at 15:38, Christoph M. Becker 
>> wrote:
>>
>>> On 11.07.2022 at 21:04, Hans Henrik Bergan wrote:
>>>
>>> > Any of you windows.php.net guys familiar with SSH? Can one be created?
>>>
>>> That would be possible (needed to be set-up by Alex Schoenmaker), but
>>> while that could solve the upload issue, it wouldn't solve the other
>>> issue I've mentioned, namely that we need to

Re: [PHP-DEV] Windows PECL build machine died

[Hans Henrik Bergan]

Fwiw Chris Haas / vendiadvertising.com has reached out, they're willing to
sponsor raid(1) if my proposal is accepted.
Haas is reading this mailing list, but does not wish to participate/post
directly at present.
(I have no prior relation, never heard of them before today)

On Tue, 12 Jul 2022 at 22:31, Hans Henrik Bergan 
wrote:

> i have a 40-core 128GB RAM server with 1 (and only 1) static ipv4 address
> that I intend to keep around until at least 27 november 2025 (but unsure
> after that),
> it has more RAM/CPU than i need, and i could set up a virtual machine on
> it and give VNC access to the VM in the form of
> > ssh -L :localhost:3389 user@ip
> then point a RDP/VNC client to localhost:
> i can dedicate individual TCP ports to it, but not any of 22, 80, 443,
> 5900,  5901, 8083, , 587, 2525
> (after which i can recommend Teamviewer for a more comfortable access)
>
> but the server has several caveats:
> - it's un-raided, rolling just a single 1TB SSD, if that SSD was to die,
> everything on it would be lost, and it would probably take days to replace
> the drive.
> - it's located in a somewhat unstable environment, occasional power
> outage, it was out on 30 june, 23 june, 27 january, and in 2021 was down on
> 30 august. (it boots up and recovers automatically, but it has a reboot
> time of roughly 300 seconds until ssh responds again)
> - I can not offer a dedicated IP (but can offer some dedicated ports)
> - May be decommissioned after 27-11-2025
>
> If that sounds like a good idea, I'll want a ssh public key.
>
>
> On Tue, 12 Jul 2022 at 15:38, Christoph M. Becker 
> wrote:
>
>> On 11.07.2022 at 21:04, Hans Henrik Bergan wrote:
>>
>> > Any of you windows.php.net guys familiar with SSH? Can one be created?
>>
>> That would be possible (needed to be set-up by Alex Schoenmaker), but
>> while that could solve the upload issue, it wouldn't solve the other
>> issue I've mentioned, namely that we need to avoid dynamically linking
>> against incompatible versions of dependencies.  And there is yet another
>> issue, namely security.  I think these issues can only be solved by some
>> central place where the packages are build.
>>
>> > On Mon, 11 Jul 2022 at 19:52, Christoph M. Becker 
>> wrote:
>> >
>> >> On 11.07.2022 at 18:53, Hans Henrik Bergan wrote:
>> >>
>> >>> Is there any SSH public key associated with the Windows php
>> developers?
>> >> Or
>> >>> with CMB?
>> >>
>> >> No.  At least not regarding windows.php.net.
>> >>
>> >>> On Mon, 11 Jul 2022 at 18:25, Christoph M. Becker 
>> >> wrote:
>> >>>
>> >>>> On 11.07.2022 at 17:41, Hans Henrik Bergan wrote:
>> >>>>
>> >>>>> Do you mean it is unlikely that Github Actions will suffice? because
>> >> that
>> >>>>> would definitely be a great solution if it was possible/feasible .
>> >>>>
>> >>>> No.  It is only unlikely that automated uploads to window.php.net
>> will
>> >>>> ever be possible using GH actions.
>> >>>>
>> >>>>> Anyway, with regards to "I don't think there are special
>> requirements
>> >>>>> regarding the hardware", can you give a rough estimate on RAM/disk
>> >> space
>> >>>>> requirements?
>> >>>>
>> >>>> The old machine had something like 4 or 8 GB RAM, and a 128 GB hard
>> >> disk.
>> >>>>
>> >>>
>> >>
>> >
>>
>>

Re: [PHP-DEV] Windows PECL build machine died

[Hans Henrik Bergan]

i have a 40-core 128GB RAM server with 1 (and only 1) static ipv4 address
that I intend to keep around until at least 27 november 2025 (but unsure
after that),
it has more RAM/CPU than i need, and i could set up a virtual machine on it
and give VNC access to the VM in the form of
> ssh -L :localhost:3389 user@ip
then point a RDP/VNC client to localhost:
i can dedicate individual TCP ports to it, but not any of 22, 80, 443,
5900,  5901, 8083, , 587, 2525
(after which i can recommend Teamviewer for a more comfortable access)

but the server has several caveats:
- it's un-raided, rolling just a single 1TB SSD, if that SSD was to die,
everything on it would be lost, and it would probably take days to replace
the drive.
- it's located in a somewhat unstable environment, occasional power outage,
it was out on 30 june, 23 june, 27 january, and in 2021 was down on 30
august. (it boots up and recovers automatically, but it has a reboot time
of roughly 300 seconds until ssh responds again)
- I can not offer a dedicated IP (but can offer some dedicated ports)
- May be decommissioned after 27-11-2025

If that sounds like a good idea, I'll want a ssh public key.


On Tue, 12 Jul 2022 at 15:38, Christoph M. Becker  wrote:

> On 11.07.2022 at 21:04, Hans Henrik Bergan wrote:
>
> > Any of you windows.php.net guys familiar with SSH? Can one be created?
>
> That would be possible (needed to be set-up by Alex Schoenmaker), but
> while that could solve the upload issue, it wouldn't solve the other
> issue I've mentioned, namely that we need to avoid dynamically linking
> against incompatible versions of dependencies.  And there is yet another
> issue, namely security.  I think these issues can only be solved by some
> central place where the packages are build.
>
> > On Mon, 11 Jul 2022 at 19:52, Christoph M. Becker 
> wrote:
> >
> >> On 11.07.2022 at 18:53, Hans Henrik Bergan wrote:
> >>
> >>> Is there any SSH public key associated with the Windows php developers?
> >> Or
> >>> with CMB?
> >>
> >> No.  At least not regarding windows.php.net.
> >>
> >>> On Mon, 11 Jul 2022 at 18:25, Christoph M. Becker 
> >> wrote:
> >>>
> >>>> On 11.07.2022 at 17:41, Hans Henrik Bergan wrote:
> >>>>
> >>>>> Do you mean it is unlikely that Github Actions will suffice? because
> >> that
> >>>>> would definitely be a great solution if it was possible/feasible .
> >>>>
> >>>> No.  It is only unlikely that automated uploads to window.php.net
> will
> >>>> ever be possible using GH actions.
> >>>>
> >>>>> Anyway, with regards to "I don't think there are special requirements
> >>>>> regarding the hardware", can you give a rough estimate on RAM/disk
> >> space
> >>>>> requirements?
> >>>>
> >>>> The old machine had something like 4 or 8 GB RAM, and a 128 GB hard
> >> disk.
> >>>>
> >>>
> >>
> >
>
>

Re: [PHP-DEV] Windows PECL build machine died

[Hans Henrik Bergan]

Any of you windows.php.net guys familiar with SSH? Can one be created?

On Mon, 11 Jul 2022 at 19:52, Christoph M. Becker  wrote:

> On 11.07.2022 at 18:53, Hans Henrik Bergan wrote:
>
> > Is there any SSH public key associated with the Windows php developers?
> Or
> > with CMB?
>
> No.  At least not regarding windows.php.net.
>
> > On Mon, 11 Jul 2022 at 18:25, Christoph M. Becker 
> wrote:
> >
> >> On 11.07.2022 at 17:41, Hans Henrik Bergan wrote:
> >>
> >>> Do you mean it is unlikely that Github Actions will suffice? because
> that
> >>> would definitely be a great solution if it was possible/feasible .
> >>
> >> No.  It is only unlikely that automated uploads to window.php.net will
> >> ever be possible using GH actions.
> >>
> >>> Anyway, with regards to "I don't think there are special requirements
> >>> regarding the hardware", can you give a rough estimate on RAM/disk
> space
> >>> requirements?
> >>
> >> The old machine had something like 4 or 8 GB RAM, and a 128 GB hard
> disk.
> >>
> >
>

Re: [PHP-DEV] Windows PECL build machine died

[Hans Henrik Bergan]

Is there any SSH public key associated with the Windows php developers? Or
with CMB?

On Mon, 11 Jul 2022 at 18:25, Christoph M. Becker  wrote:

> On 11.07.2022 at 17:41, Hans Henrik Bergan wrote:
>
> > Do you mean it is unlikely that Github Actions will suffice? because that
> > would definitely be a great solution if it was possible/feasible .
>
> No.  It is only unlikely that automated uploads to window.php.net will
> ever be possible using GH actions.
>
> > Anyway, with regards to "I don't think there are special requirements
> > regarding the hardware", can you give a rough estimate on RAM/disk space
> > requirements?
>
> The old machine had something like 4 or 8 GB RAM, and a 128 GB hard disk.
>

Re: [PHP-DEV] Windows PECL build machine died

[Hans Henrik Bergan]

Do you mean it is unlikely that Github Actions will suffice? because that
would definitely be a great solution if it was possible/feasible .

Anyway, with regards to "I don't think there are special requirements
regarding the hardware", can you give a rough estimate on RAM/disk space
requirements?

Re: [PHP-DEV] [RFC][Vote] Auto-capture closures

[Hans Henrik Bergan]

>But do any of them auto-capture by value?

in c++ it's optional if you want to capture-by-value or
capture-by-reference, [&]()->void{...}(); captures everything by reference
and [=]()mutable->void{...}(); captures everything by value

> I think that's still explicit

fair assessment


On Sat, 2 Jul 2022 at 05:02, Anton Smirnov  wrote:

> On Fri, 2022-07-01 at 16:11 +0200, Hans Henrik Bergan wrote:
> > > As far as we are aware, only two languages in widespread use
> > > require variables to be explicitly closed over: PHP and C++. All
> > > other major languages capture implicitly, as is proposed here.
>
> But do any of them auto-capture by value?
>
> > to be fair to c++, it supports [&] to capture everything, like
> > int a=1,b=2,c=3;[&]()->void{std::cout << a << b << c;}();
>
> I think that's still explicit
>
> --
> Anton
>

Re: [PHP-DEV] [RFC][Vote] Auto-capture closures

[Hans Henrik Bergan]

>As far as we are aware, only two languages in widespread use require
variables to be explicitly closed over: PHP and C++. All other major
languages capture implicitly, as is proposed here.

to be fair to c++, it supports [&] to capture everything, like
int a=1,b=2,c=3;[&]()->void{std::cout << a << b << c;}();


On Fri, 1 Jul 2022 at 16:05, Larry Garfield  wrote:

> Greetings, Internalians.
>
> The vote for auto-capture closures is now open.  It will run until 15 July.
>
> https://wiki.php.net/rfc/auto-capture-closure
>
> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Hans Henrik Bergan]

(dammit, mixed sftp:// with ftps:// there, ignore that, i meant sftp:// )

On Wed, 22 Jun 2022 at 16:53, Hans Henrik Bergan 
wrote:

> nitpicking but I kind-of doubt the description
> for CurlUrl::NO_DEFAULT_PORT is correct, quote:
> > Instructs the method to return null if the port matches the default port
> for the scheme.
>
> makes it sound like these would return null: http://localhost:80/
> https://localhost:443/ ftps://localhost:22/
>
> Is that correct? I would imagine it returns null if the port isn't
> specified, rather than null if the port when specified matches the default
> port?
>
> On Wed, 22 Jun 2022 at 16:46, Hans Henrik Bergan 
> wrote:
>
>> any particular reason CurlUrl::getPort() defaults to 0 rather than one of
>> the valid options? (that being CurlUrl::DEFAULT_PORT
>> and CurlUrl::NO_DEFAULT_PORT )
>>
>> On Wed, 22 Jun 2022 at 16:23, Pierrick Charron  wrote:
>>
>>> Hi Derick,
>>>
>>>
>>> >
>>> > - The new CurlUrl class should probably be immutable from the start. It
>>> > was my biggest mistake not to do that with DateTime.
>>> >
>>> >
>>> Thanks for sharing your lessons learned. But I still see some use cases
>>> where mutable objects are easier to use. From the experience you had with
>>> DateTime, do you think that having `CurlUrl` being immutable and
>>> providing
>>> a `MutableCurlUrl` would make sense ? I see some cases where you
>>> "navigate"
>>> on a website using the same CurlHandle and just want to manipulate the
>>> MutableCurlUrl handle to change urls.
>>>
>>>
>>> > - What happens if the curl library available on the system does not
>>> have
>>> > the features and functions that this new class relies on? I would
>>> expect
>>> > the class to not be available either, but the RFC does not mention
>>> that.
>>> >
>>>
>>> Good point. As you expected, if the functions are not available in
>>> libcurl,
>>> the class will not be available. Same thing for each constant/feature.
>>> The
>>> extension will "adapt" to the curl version. I will add this to the RFC.
>>>
>>> Pierrick
>>>
>>

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Hans Henrik Bergan]

nitpicking but I kind-of doubt the description for CurlUrl::NO_DEFAULT_PORT
is correct, quote:
> Instructs the method to return null if the port matches the default port
for the scheme.

makes it sound like these would return null: http://localhost:80/
https://localhost:443/ ftps://localhost:22/

Is that correct? I would imagine it returns null if the port isn't
specified, rather than null if the port when specified matches the default
port?

On Wed, 22 Jun 2022 at 16:46, Hans Henrik Bergan 
wrote:

> any particular reason CurlUrl::getPort() defaults to 0 rather than one of
> the valid options? (that being CurlUrl::DEFAULT_PORT
> and CurlUrl::NO_DEFAULT_PORT )
>
> On Wed, 22 Jun 2022 at 16:23, Pierrick Charron  wrote:
>
>> Hi Derick,
>>
>>
>> >
>> > - The new CurlUrl class should probably be immutable from the start. It
>> > was my biggest mistake not to do that with DateTime.
>> >
>> >
>> Thanks for sharing your lessons learned. But I still see some use cases
>> where mutable objects are easier to use. From the experience you had with
>> DateTime, do you think that having `CurlUrl` being immutable and providing
>> a `MutableCurlUrl` would make sense ? I see some cases where you
>> "navigate"
>> on a website using the same CurlHandle and just want to manipulate the
>> MutableCurlUrl handle to change urls.
>>
>>
>> > - What happens if the curl library available on the system does not have
>> > the features and functions that this new class relies on? I would expect
>> > the class to not be available either, but the RFC does not mention that.
>> >
>>
>> Good point. As you expected, if the functions are not available in
>> libcurl,
>> the class will not be available. Same thing for each constant/feature. The
>> extension will "adapt" to the curl version. I will add this to the RFC.
>>
>> Pierrick
>>
>

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Hans Henrik Bergan]

any particular reason CurlUrl::getPort() defaults to 0 rather than one of
the valid options? (that being CurlUrl::DEFAULT_PORT
and CurlUrl::NO_DEFAULT_PORT )

On Wed, 22 Jun 2022 at 16:23, Pierrick Charron  wrote:

> Hi Derick,
>
>
> >
> > - The new CurlUrl class should probably be immutable from the start. It
> > was my biggest mistake not to do that with DateTime.
> >
> >
> Thanks for sharing your lessons learned. But I still see some use cases
> where mutable objects are easier to use. From the experience you had with
> DateTime, do you think that having `CurlUrl` being immutable and providing
> a `MutableCurlUrl` would make sense ? I see some cases where you "navigate"
> on a website using the same CurlHandle and just want to manipulate the
> MutableCurlUrl handle to change urls.
>
>
> > - What happens if the curl library available on the system does not have
> > the features and functions that this new class relies on? I would expect
> > the class to not be available either, but the RFC does not mention that.
> >
>
> Good point. As you expected, if the functions are not available in libcurl,
> the class will not be available. Same thing for each constant/feature. The
> extension will "adapt" to the curl version. I will add this to the RFC.
>
> Pierrick
>

[PHP-DEV] Re: LOCK_SH for file_get_contents ?

[Hans Henrik Bergan]

can we at least change FILE_USE_INCLUDE_PATH to 8 / (1<<3)  ? that would
allow a userland implementation of file_get_contents to support LOCK_SH and
FILE_USE_INCLUDE_PATH

The current situation is so bad that FILE_USE_INCLUDE_PATH literally cannot
be used in strict_mode=1, it's pretty much completely useless since php
7.0, so I doubt it'll break anything keeping up with new releases of PHP.

On Mon, 13 Dec 2021 at 13:57, Hans Henrik Bergan 
wrote:

> This has been requested for years (since at least 2009?) but it seems no
> actual plan has been proposed
> How about this?
> since we already have the constant FILE_USE_INCLUDE_PATH , seems it was
> introduced in PHP5.0.0,
>
> 1: FILE_USE_INCLUDE_PATH currently collides with LOCK_SH (they're both 1),
> lets change FILE_USE_INCLUDE_PATH to something that doesn't collide with
> any of LOCK_SH | LOCK_EX | LOCK_NB
> for example  (1 << 3) / int(8)
> 2: change argument #2 from "bool $use_include_path = false" to "int|bool
> $flags = 0" , treating bool(false) the same as int(0) and bool(true) the
> same as FILE_USE_INCLUDE_PATH , and support LOCK_SH | LOCK_NB |
> FILE_USE_INCLUDE_PATH here
> (i think LOCK_EX could also be supported, but that might be controversial,
> and the use case is certainly limited, if there is one at all)
>
> because it's kind of silly, and at times annoying, that file_put_contents
> support LOCK_EX but file_get_contents does not support LOCK_SH
>

Re: [PHP-DEV] Re: Undefined variables and the array append operator

[Hans Henrik Bergan]

> RFC. There are other inconsistencies as well now, depending on how the
undefined variable comes to exist

absolutely, but shouldn't try to do too much in a single rfc, wouldn't want
it to be rejected for the wrong reasons ^^

On Wed, 30 Mar 2022 at 12:17, Björn Larsson via internals <
internals@lists.php.net> wrote:

> Den 2022-03-29 kl. 21:44, skrev Rowan Tommins:
> > Hi all,
> >
> > If $foo is not defined, statements such as $foo += 1 and $foo .= 'blah'
> > raise "undefined variable" Warnings in PHP 8, and will throw Errors in
> > PHP 9. However, the very similar looking $foo[] = 1 succeeds silently.
> >
> > This seems odd to me, as "append to string" and "append to array" seem
> > like very similar operations, with most of the same use cases and
> > possible bugs.
> >
> >
> >  From an *implementation* point of view, this is presumably because they
> > are defined as different Op Codes - ASSIGN_OP for .= and ASSIGN_DIM for
> > []=, I believe. But that doesn't explain *why* ASSIGN_DIM behaves this
> way.
> >
> > A *historical* explanation might relate to Perl's "autovivification"
> > feature. However, PHP does *not* implement the same rules as Perl: for
> > instance, Perl will create array dimensions just by reading them, which
> > PHP does not; and Perl has a completely different type system, with
> > cases like "a scalar becomes a reference to a hash unless already a
> > reference to a list". Note also that I'm *not* talking about
> > multi-dimensional arrays with missing keys here, only undefined local
> > variables, as were the subject of the recent RFC.
> >
> > The *observable behaviour* for most operators in PHP is the same:
> >
> > 1) if the variable is undefined, consider the value to be null
> > 2) coerce the value to the appropriate type; if the value is null, this
> > gives the relevant "empty" value, such as '', 0, or []
> > 3) apply the operator
> >
> > There isn't anything particularly special with $foo[] = 'bar' in this
> > case, except that it's the only operator that doesn't raise a Warning
> > (and planned Error) at step 1. The same goes for all the other uses of
> > the [] syntax I can think of, like $foo['key'] = 'bar', or $ref =&
> $foo[].
> >
> >
> > For example, consider the following simple validation code
> > [https://3v4l.org/pP5CU]:
> >
> > $requiredFields = ['name', 'age', 'hair_colour'];
> >
> > // Note: $errorString is not initialised
> > foreach ( $requiredFields as $field ) {
> >  if ( ! isset($_POST[$field]) ) {
> >  $errorString .= "Missing required field '$field'. ";
> >  }
> > }
> > echo $errorString;
> >
> > This gives an "Undefined variable" Notice / Warning / Error, depending
> > on the version. That's reasonable, as failing to initialise $errorString
> > might cause problems if this code is integrated into a loop or larger
> > function later.
> >
> > However, switch the code from building up a string to building up an
> > array, and the result is identical, but the Notice / Warning / Error
> > goes away [https://3v4l.org/ojZ1O]:
> >
> > // Note: $errorArray is not initialised
> > foreach ( $requiredFields as $field ) {
> >  if ( ! isset($_POST[$field]) ) {
> >  $errorArray[] = "Missing required field '$field'. ";
> >  }
> > }
> > echo implode('', $errorArray);
> >
> >
> > Can anyone give a compelling reason why we should keep this
> > inconsistency, or should I raise an RFC to bring it in line with other
> > undefined variable accesses?
> >
> >
> I think it deserves an RFC. Then we also capture your excellent
> explanation above!
>
> Regards //Björn L
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

[Hans Henrik Bergan]

i'd write it as
$name = "Theodore Brown";
echo "{$name} has a length of " . strlen ( $name ) . ".";

On Fri, 18 Mar 2022 at 05:49, Theodore Brown  wrote:

> On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm 
> wrote:
>
> > On Thu, 17 Mar 2022, 23:27 Ilija Tovilo,  wrote:
> >
> >> Hi everyone
> >>
> >> I'd like to start discussion on a new RFC for arbitrary string
> >> interpolation.
> >> https://wiki.php.net/rfc/arbitrary_string_interpolation
> >>
> >> Let me know what you think.
> >
> > That is a cool idea.
> > But I am not a big fan of having code in strings.
> > Wouldn’t this open the door to all kinds of new attacks?
>
> Do you have an example of a new kind of attack this would allow?
> The proposal doesn't enable interpolation of strings coming from
> a database or user input - it only applies to string literals
> directly in PHP code.
>
> Personally I'm really looking forward to having this functionality.
> Just a couple days ago I wanted to call a function in an interpolated
> string, and it was really annoying to have to wrap the function in a
> closure in order to use it.
>
> If this RFC is accepted I'd be able to replace code like this:
>
> $name = "Theodore Brown";
> $strlen = fn(string $string): int => strlen($string);
> echo "{$name} has a length of {$strlen($name)}.";
>
> with
>
> $name = "Theodore Brown";
> echo "{$name} has a length of {$:strlen($name)}.";
>
>
> Sincerely,
>
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Hans Henrik Bergan]

fwiw i recall a real-world script modifying a linux system's /etc/passwd /
/etc/shadow using crypt() because password_hash() couldn't create
passwd/shadow-compatible hashes while crypt() could

On Mon, 21 Feb 2022 at 12:49, Marco Pivetta  wrote:

> On Mon, Feb 21, 2022 at 12:39 PM Tim Düsterhus  wrote:
>
> > Hi
> >
> > On 2/21/22 12:12, Marco Pivetta wrote:
> >  If it's not going to be removed, what's the point of annoying people
> >  with deprecation warnings (that they would patch out/silence
> anyway)?
> > 
> > >>>
> > >>> Probably to be removed in `9.0` or `10.0`? Yes, it should be removed
> at
> > >>> some point.
> > >>
> > >> In contrast to other deprecations (e.g. the utf8_encode/decode
> currently
> > >> discussed), deprecating and ultimately removing crypt() results in an
> > >> actual loss of functionality.
> > >>
> > >
> > > ...yes? That's the point?
> > >
> >
> > I understand that that's the point. However I agree with Stas that this
> > would be a BC break with no practical gain and I articulated the reasons
> > why I believe that: If crypt() is what you need, then crypt() is what
> > you need and being told that your use-case is invalid is not helping
> > you. The function already exists and I assume that it does not require
> > (relevant) maintenance effort for PHP maintainers keeping it.
> >
>
> Not a maintenance effort exercise, but a user education exercise.
> Users need to stop using `crypt()`, because it just has to stop, period.
> They have a period of time to migrate away from it, and then they will get
> a hard crash when it's gone-gone-gone, which is **OK**.
>
> In addition to that, end-users of PHP-SRC are not paying customers to the
> php foundation, and their systems will keep rotting until they will finally
> have to touch them: it would be a different story if there was a LTS
> contract in place, but that's not how OSS works.
>
> They can also polyfill it with whatever crazy and broken contraption works
> for them, as long as they take the irresponsible security decision upon
> themselves.
>
> Calibrated code and feature removal is part of the software maintenance
> process, and it has more effects than just code size increase.
>
>
>
> > With the same arguments one could deprecate and remove md5() (and
> > possibly sha1() as well). It should not be used for passwords, it should
> > not be used for signatures and any new use should require *careful*
> > review. Nonetheless there are cases where you still need an
> > implementation of md5() and then not having md5() is an issue.
> >
> > If someone proposed the removal of md5() I'd disagree the same.
> >
>
> As mentioned elsewhere in the mail thread, `crypt()` is not designed for
> fast hashing, and is in fact slow by design.
> MD5 and SHA1 still have a place, compared to that, as they are not designed
> solely for password hashing.
>
> This is part of "calibrated code and feature removal" from above.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.io/
>

Re: [PHP-DEV] [VOTE] RFC: Remove support for libmysql from mysqli

[Hans Henrik Bergan]

good job! can we do PDO_MYSQL next? if that also goes away (seems likely),
all libmysqlclient-specific code can be removed i think

On Sat, 5 Feb 2022 at 16:10, Kamil Tekiela  wrote:

> The voting has now ended. The RFC has been unanimously accepted (30/0).
>
> Since PHP 8.2 it will not be possible to compile mysqli with libmysql.
>
> Kind regards,
> Kamil
>
> >
>

Re: [PHP-DEV] header() allows arbitrary status codes

[Hans Henrik Bergan]

another thing, it wouldn't surprise me if someone at some point want to
emulate some IIS-specific codes in PHP, like
header("HTTP/1.1 401.3 Unauthorized due to ACL on resource.");

it'd be a shame if PHP literally cannot send IIS-errorcodes

On Thu, 23 Dec 2021 at 16:40, Hans Henrik Bergan 
wrote:

> sometime in the future HTTP 6xx will be defined, and we'll have to add a
> big warning to the header()/http_respons_code() pages like
> "Warning: HTTP 6.x.x is only supported in PHP >= x.x.x and PHP <=8.1.x",
> and library developers have to add fugly code like
> `if(PHP_VERSION_MAJOR >= X || (PHP_VERSION_MAJOR <=8 && PHP_VERSION_MINOR
> <= 1){http_response_code(6xx);}else{
> trigger_error("your php version cannot use http 6xx");
> }
>
> i'd prefer if we didn't restrict the header ranges
>
> On Thu, 23 Dec 2021 at 13:47, Paul Dragoonis  wrote:
>
>> On Thu, 23 Dec 2021, 00:06 David Gebler,  wrote:
>>
>> > On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker 
>> > wrote:
>> >
>> > > Hi all,
>> > >
>> > > a while ago it has been reported[1] that our header() function
>> actually
>> > > allows arbitrary status codes, which may even overflow.  Of course,
>> that
>> > > makes no sense, since the status code is supposed to be a three digit
>> > > code.  So this ticket has been followed up by a pull request[2], and
>> > > Jakub suggested to further restrict the status code to be in range
>> 100 -
>> > > 599.
>> > >
>> >
>> > Personally, I don't like restricting the status code to a number in the
>> > 100-599 range. As far as I know, RFC 7230 doesn't mandate anything
>> beyond
>> > the requirement of 3 digits and while 7231 may only specify semantics
>> for
>> > 1xx-5xx, that doesn't mean there isn't a legitimate use-case in custom
>> or
>> > internal applications for status codes outside the usual semantics.
>> >
>> > The overflow part is a legit bug which can and should be fixed, but I'd
>> at
>> > least question whether a user should be obliged to stick to conventional
>> > HTTP semantics via the header() function, or even a strictly conformant
>> > implementation of the standards defined 7320. Maybe this behaviour
>> could be
>> > default but overridable via a new, fourth optional parameter or
>> something,
>> > I don't know...but I can easily imagine someone having a legitimate
>> context
>> > in which they want to send status codes outside the usual range
>> > representing custom semantics.
>> >
>>
>>
>> I think its safe to say we should restrict the overflow parts.
>>
>> As for boundaries; I don't know who is or isn't using their own custom
>> status codes. It's unlikely, but entirely possible. As such, this is
>> considered a BC break.
>>
>> If we apply restrictions to a minor release, then upgrading will be harder
>> for 8.2 if we include this in the next release.
>>
>> You could say 98% of people are using standard ranges for status codes,
>> but
>> we do have to always take into account the 2% on our decisions.
>>
>> Thanks.
>>
>>
>>
>>
>> >
>> > >
>> > > Since this could break some pathological cases, I wanted to ask
>> whether
>> > > anybody objects to this change for the master branch (i.e. PHP 8.2).
>> > >
>> > > [1] <https://bugs.php.net/bug.php?id=81645>
>> > > [2] <https://github.com/php/php-src/pull/7676>
>> > >
>> > > Christoph
>> > >
>> > > --
>> > > PHP Internals - PHP Runtime Development Mailing List
>> > > To unsubscribe, visit: https://www.php.net/unsub.php
>> > >
>> > >
>> >
>>
>

Re: [PHP-DEV] header() allows arbitrary status codes

[Hans Henrik Bergan]

sometime in the future HTTP 6xx will be defined, and we'll have to add a
big warning to the header()/http_respons_code() pages like
"Warning: HTTP 6.x.x is only supported in PHP >= x.x.x and PHP <=8.1.x",
and library developers have to add fugly code like
`if(PHP_VERSION_MAJOR >= X || (PHP_VERSION_MAJOR <=8 && PHP_VERSION_MINOR
<= 1){http_response_code(6xx);}else{
trigger_error("your php version cannot use http 6xx");
}

i'd prefer if we didn't restrict the header ranges

On Thu, 23 Dec 2021 at 13:47, Paul Dragoonis  wrote:

> On Thu, 23 Dec 2021, 00:06 David Gebler,  wrote:
>
> > On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker 
> > wrote:
> >
> > > Hi all,
> > >
> > > a while ago it has been reported[1] that our header() function actually
> > > allows arbitrary status codes, which may even overflow.  Of course,
> that
> > > makes no sense, since the status code is supposed to be a three digit
> > > code.  So this ticket has been followed up by a pull request[2], and
> > > Jakub suggested to further restrict the status code to be in range 100
> -
> > > 599.
> > >
> >
> > Personally, I don't like restricting the status code to a number in the
> > 100-599 range. As far as I know, RFC 7230 doesn't mandate anything beyond
> > the requirement of 3 digits and while 7231 may only specify semantics for
> > 1xx-5xx, that doesn't mean there isn't a legitimate use-case in custom or
> > internal applications for status codes outside the usual semantics.
> >
> > The overflow part is a legit bug which can and should be fixed, but I'd
> at
> > least question whether a user should be obliged to stick to conventional
> > HTTP semantics via the header() function, or even a strictly conformant
> > implementation of the standards defined 7320. Maybe this behaviour could
> be
> > default but overridable via a new, fourth optional parameter or
> something,
> > I don't know...but I can easily imagine someone having a legitimate
> context
> > in which they want to send status codes outside the usual range
> > representing custom semantics.
> >
>
>
> I think its safe to say we should restrict the overflow parts.
>
> As for boundaries; I don't know who is or isn't using their own custom
> status codes. It's unlikely, but entirely possible. As such, this is
> considered a BC break.
>
> If we apply restrictions to a minor release, then upgrading will be harder
> for 8.2 if we include this in the next release.
>
> You could say 98% of people are using standard ranges for status codes, but
> we do have to always take into account the 2% on our decisions.
>
> Thanks.
>
>
>
>
> >
> > >
> > > Since this could break some pathological cases, I wanted to ask whether
> > > anybody objects to this change for the master branch (i.e. PHP 8.2).
> > >
> > > [1] 
> > > [2] 
> > >
> > > Christoph
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: https://www.php.net/unsub.php
> > >
> > >
> >
>

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

[Hans Henrik Bergan]

I wonder if anyone depends on utf8_* without also depending on mb_* ? I
imagine that is exceedingly rare

On Wed, Dec 22, 2021, 15:26 Rowan Tommins  wrote:

> On 22/12/2021 10:45, Andreas Heigl wrote:
> > I just dug a bit deeper on the subject and found this RFC from 2016:
> >
> > https://wiki.php.net/rfc/remove_utf_8_decode_encode
> >
> > Perhaps we can just revive that one!
>
>
> As I say, I have a draft with lots more detail in, which I will tidy up
> after Christmas. I deliberately didn't link to it, because I want to
> re-read it myself before letting other people comment on it, and don't
> have the time right now.
>
> My current inclination is to deprecate in 8.next, and remove in 9.0, but
> I want to make sure the argument for that is solid before putting it to
> a vote.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] LOCK_SH for file_get_contents ?

[Hans Henrik Bergan]

This has been requested for years (since at least 2009?) but it seems no
actual plan has been proposed
How about this?
since we already have the constant FILE_USE_INCLUDE_PATH , seems it was
introduced in PHP5.0.0,

1: FILE_USE_INCLUDE_PATH currently collides with LOCK_SH (they're both 1),
lets change FILE_USE_INCLUDE_PATH to something that doesn't collide with
any of LOCK_SH | LOCK_EX | LOCK_NB
for example  (1 << 3) / int(8)
2: change argument #2 from "bool $use_include_path = false" to "int|bool
$flags = 0" , treating bool(false) the same as int(0) and bool(true) the
same as FILE_USE_INCLUDE_PATH , and support LOCK_SH | LOCK_NB |
FILE_USE_INCLUDE_PATH here
(i think LOCK_EX could also be supported, but that might be controversial,
and the use case is certainly limited, if there is one at all)

because it's kind of silly, and at times annoying, that file_put_contents
support LOCK_EX but file_get_contents does not support LOCK_SH

Re: [PHP-DEV] [VOTE] Locale-independent case conversion

[Hans Henrik Bergan]

btw why is this code *not* getting dotted capital i on 3v4l?
https://3v4l.org/D1WG1#v7.4.26
it gets ["res_hex"]=> string(2) "49"

$str,
"str_hex"=>bin2hex($str),
"res"=>$res,
"res_hex"=>bin2hex($res),
]);
?>

On Thu, 25 Nov 2021 at 09:57, Côme Chilliet  wrote:

> Le jeudi 25 novembre 2021, 06:05:37 CET Tim Starling a écrit :
> > Voting is now open for my RFC on locale-independent case conversion.
> >
> > https://wiki.php.net/rfc/strtolower-ascii
>
> Hello,
>
> The RFC is missing information about alternatives:
> Do all of these function have an mbstring version?
> Are those locale dependant or have an option for it?
>
> To reuse the example from the RFC, if I want to convert a UTF string to
> uppercase using Turkish rules and get dotted capital I, what should I use?
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Proposal: &$result_code=null parameter in shell_exec()

[Hans Henrik Bergan]

> then the backtick operator will not behave identically anymore. Am I
correct?

yeah kindof-correct, the backtick operator would then behave identically to
giving shell_exec() only 1 argument, or null as the 2nd argument
(btw i'm the guy that made the linked bugs.php.net feature request)

while we're on the topic of shell_exec(), does anyone happen to know why
shell_exec() pipes in *text mode*/binary-corruption-mode on windows?


On Thu, 18 Nov 2021 at 09:19, Kamil Tekiela  wrote:

> Hi Luca,
>
> How will this change be reflected in its alias, the backtick operator? If
> the plan is to change the signature of shell_exec() then the backtick
> operator will not behave identically anymore. Am I correct?
>
> Regards,
> Kamil
>

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Hans Henrik Bergan]

if hosting it ourself is a priority, i suggest looking into GitLab’s
Community Edition, which is entirely open source,
and the GNOME project moved from Bugzilla to GitLab CE in 2018,
here's how that worked out, 2 years later:
https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/
(and the TL;DR is that it worked out great for the GNOME project)


On Mon, 15 Nov 2021 at 10:47, Derick Rethans  wrote:

> Dear Internals,
>
> I think it is a mistake to decide on a whim to move over to GitHub
> issues without having evaluated anything else.
>
> GitHub is a proprietary platform, where unlike with the code
> repositories, the interactions and issues are not easy to migrate out of
> again. It is also now owned by MSFT, and although they are making
> friendly noises towards Open Source, I remain largely skeptical (with as
> a hint, the stuff they're pulling with AI code completion).
>
> I understand and share that "bugsnet" has many issues, and I don't
> necessarily object moving to something else.
>
> However, in the last 25+ years we've always hosted this ourselves, and
> this prevented any sort of vendor lock in. I think it is important to
> own our own data here, or at least have full access to any interactions.
>
> This jump to GitHub Issues feels rushed, and I worry that we end up
> making the wrong decision, especially because from the RFC it seems we
> need to build some functionality (tags scheme, for example) on top of
> it. And this will need to be maintained separately, and I worry that too
> few people are going to be interested in gardening the issues on GH.
>
> I believe we would be much better served having a look what is
> available, and see what else is suitable. I'm therefore intending to
> vote no on this.
>
> cheers,
> Derick
>
>
> On Tue, 2 Nov 2021, Nikita Popov wrote:
>
> > Hi internals,
> >
> > The migration from bugs.php.net to GitHub issues has already been
> discussed
> > in https://externals.io/message/114300 and has already happened for
> > documentation issues.
> >
> > I'd like to formally propose to use GitHub for PHP implementation issues
> as
> > well: https://wiki.php.net/rfc/github_issues
> >
> > Regards,
> > Nikita
> >
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] search on bugs.php.net appears to be semi-broken ?

[Hans Henrik Bergan]

for whatever reason, searching for "fpassthru" on bugs.php.net does not
find https://bugs.php.net/bug.php?id=39135 ,
titled "fpassthru with optional argument length" - screenshot:
https://i.imgur.com/gUjNYBz.png

that nearly caused me to make a duplicate of 39135 today

[PHP-DEV] fpassthru should get an optional length argument

[Hans Henrik Bergan]

ref https://bugs.php.net/bug.php?id=39135 ,
i was thinking about how to implement HTTP Range requests/HTTP 206 Partial
Content in userland php,
 and ofc it's possible to implement using fread() loops, but it'd be easier
(and faster? presumably) to implement if fpassthru() natively supported a
$max_bytes=null argument,

an example of where it would be useful:

Re: [PHP-DEV] Deprecation of ext/date ISO8061 constants

[Hans Henrik Bergan]

>> the topic was controversial

> Why is that? I did not found any information regarding this one on =
internals mailing list.

mostly because people who have never read the actual ISO8601 specs, or have
just skimmed it,
swear that "yeah it's totally legal, trust me bro".. and they're loud.

it's easy to make that mistake, as the ISO8601 specs is a huge complex
mess, and does allow a shit-ton of different formats, like for example:
R8/PT72H
what does that mean, you ask? i think it means "8 repetitions over 72
hours", but i don't recall for sure.
how about P2Y10M15DT10H30M20S
i think it means 2 years 10 months~
how about R/P1Y2M15DT12H/1985-04-12T23:20:50
i think that means "something with an unknown amount of repetitions that
started in 1985 and repeated for 1 year 2 months~"
,  but i don't actually remember..

but as someone who has actually read the specs (at least the 2004 edition),
i can say with confidence that PHP's DateTime::ISO8601 is not legal in
ISO8601:2004.

also i doubt it ever was legal in any revision of ISO8601 to mix
basic-with-extended, but i don't actually know that. (did the original 1988
revision of ISO8601 allow mixing basic format with extended format? i don't
know.)



On Sun, 05 Sep 2021 at 06:01, Damian Dziaduch 
wrote:

> From php-internals  Sun Sep 05 06:01:52 2021
>> From: Damian Dziaduch 
>> Date: Sun, 05 Sep 2021 06:01:52 +
>> To: php-internals
>> Subject: [PHP-DEV] Deprecation of ext/date ISO8061 constants
>> Message-Id: <03FA66B8-D164-496C-93D4-B70B9874BB6B () icloud ! com>
>> X-MARC-Message: https://marc.info/?l=php-internals=163082172305890
>>
>> Hello internals!
>>
>> This is my first time writing here :)
>>
>> The deprecation was originally added in RFC Deprecations for PHP 8.1, =
>> but in a later stage dropped entirely:
>> =https://wiki.php.net/rfc/deprecations_php_8_1?do=3Ddiff%5B0%5D=3D1623=
>> 754059%5B1%5D=3D1623759320=3Dsidebyside
>>
>> It was already discussed on this mailing list:
>> > List:   php-internals
>> > Subject:Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
>> > From:   Nikita Popov 
>> > Date:   2021-06-15 12:23:50
>> > Message-ID: CAF+90c8wht+LpERZxj-XuY4sAYek8fH9hH_fc+JVZYg_yiAMpw () =
>> mail ! gmail ! com
>> >=20
>> > On Tue, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan =
>> 
>> > wrote:
>> >=20
>> >> i don't like this part of the RFC:
>> >=20
>> >=20
>> >>> There's a number of bug reports related to this. =46rom what I =
>> understand,
>> >>> the core problem here is not that the ISO8601 format is *wrong*, =
>> it's just
>> >>> one of multiple legal ISO-8601 formats. As DateTime formats always =
>> refer to
>> >>> a specific format, not a set of multiple possible ones, there =
>> doesn't seem
>> >>> to be anything actionable here.
>> >>=20
>> >> - this is wrong, DateTime::ISO8601 *is* illegal in ISO8601.
>> >> quoting ISO8601:2004 section 4.3.3:
>> >>=20
>> >>> For reduced accuracy, decimal or expanded representations of date =
>> and
>> >>> time of day, any of the representations in 4.1.2 (calendar dates), =
>> 4.1.3
>> >>> (ordinal dates) or 4.1.4 (week dates) followed immediately by the =
>> time
>> >>> designator [T] may be combined with any of the representations in =
>> 4.2.2.2
>> >>> through 4.2.2.4 (local time), 4.2.4 (UTC of day) or 4.2.5.2 (local =
>> time and
>> >>> the difference from UTC) provided that (...skipped stuff...) d) the
>> >>> expression shall either be completely in basic format, in which case =
>> the
>> >>> minimum number of separators necessary for the required expression =
>> is used,
>> >>> or completely in extended format, in which case additional =
>> separators shall
>> >>> be used in accordance with 4.1 and 4.2.
>> >>=20
>> >> DateTime::ISO8601 does exactly what part "d" says isn't legal,
>> >> 1970-01-01T01:00:00 is extended format, and +0100 is basic format, =
>> breaking
>> >> the "the expression shall either be completely in basic format, in =
>> which
>> >> case the minimum number of separators necessary for the required =
>> expression
>> >> is used, or completely in extended format" -part. " =
>> 1970-01-01T01:00:00" is
>> >> legal extended format but illegal basic format, and "+0100" is legal =
>> basic
>> >> format but illegal extended format, and mixing the 2 isn't legal.
>> >=20
>> > Thanks for the reference. I've removed the mention of =
>> DateTime::ISO8601
>> > from the RFC to make sure that the RFC text doesn't make any incorrect
>> > statements. Not going to include a deprecation proposal as part of =
>> this RFC
>> > though -- from past discussions, the topic was controversial, so I =
>> don't
>> > want to include it this late in the process.
>>
>> I do understand why it was dropped entirely from RFC, but I do not =
>> understand this part:
>>
>> > the topic was controversial
>>
>> Why is that? I did not found any information regarding this one on =
>> internals mailing list.
>>
>> Kind regards.
>>
>>