I think the intention was to add the readonly in the second class.

ext/posix: posix_eaccess little update and forgotten UPGRADING entry. (#10965)

Sync with EN

result may be a slot in op2. In that case SEPARATE_ARRAY() will change both result and the slot in op2. Looping over op2 and inserting the element results in both reference-less recursion which we don't allow, and increasing the refcount to 2, failing any further insertions into the array.

Avoid this by copying result into a temporary zval and performing separation there instead.

Fixes GH-10085

Alright I pushed the requested change. Thanks for reviewing! :)

Hmmm Upon adding @Girgias as reviewer GitHub auto-removed @devnexen (code-owner) review request, and now I can't add him anymore for some reason... Strange.

These values will be initialised, but the compiler can't see it. Write a dummy value to silence this.

Closes GH-10959.

This was first pointed out in GH-10959. The from_zval_... functions don't always write to the pointer, in particular it is necessary to check for an error before using the value. Otherwise we can access an uninitialized value and that's UB (and dangerous).

Note: this does NOT get rid of the compiler warning. Even though there is error checking now, the compiler isn't smart enough to figure out that the values can not be used uninitialized.

Fix uninitialized variable accesses in sockets/conversions

This was first pointed out in GH-10959. The from_zval_... functions don't always write to the pointer, in particular it is necessary to check for an error before using the value. Otherwise we can access an uninitialized value and that's UB (and dangerous).

Note: this does NOT get rid of the compiler warning. Even though there is error checking now, the compiler isn't smart enough to figure out that the values can not be used uninitialized.

Closes GH-10966.

Merge branch 'PHP-8.1' into PHP-8.2

• PHP-8.1: Fix uninitialized variable accesses in sockets/conversions

Fix uninitialized variable accesses in sockets/conversions

This was first pointed out in GH-10959. The from_zval_... functions don't always write to the pointer, in particular it is necessary to check for an error before using the value. Otherwise we can access an uninitialized value and that's UB (and dangerous).

Note: this does NOT get rid of the compiler warning. Even though there is error checking now, the compiler isn't smart enough to figure out that the values can not be used uninitialized.

Closes GH-10966.

Fix uninitialized variable accesses in sockets/conversions

This was first pointed out in GH-10959. The from_zval_... functions don't always write to the pointer, in particular it is necessary to check for an error before using the value. Otherwise we can access an uninitialized value and that's UB (and dangerous).

Note: this does NOT get rid of the compiler warning. Even though there is error checking now, the compiler isn't smart enough to figure out that the values can not be used uninitialized.

Closes GH-10966.

Merge branch 'PHP-8.1' into PHP-8.2

• PHP-8.1: Fix uninitialized variable accesses in sockets/conversions

Merge branch 'PHP-8.2'

• PHP-8.2: Fix uninitialized variable accesses in sockets/conversions

Oh legal, progressos. Ainda falta algumas coisas, e é o seguinte. Compare os arquivos:

• https://github.com/php/doc-en/blob/master/reference/curl/functions/curl-exec.xml
• https://github.com/EnzoGamaDS/doc-pt_br/blob/master/reference/curl/functions/curl-exec.xml

Esses são os arquivos no original e a tradução no fork. Os arquivos tem número de linhas diferentes, e quantidade de tags diferentes. Para poder subir o arquivo como atualizado, teria de estar com as mesmas tags, na mesma ordem.

Não sei teve a chance de ver em vídeo essa explicação, onde mostra a sincronização do texto, mantendo a mesma indentação e quantidade de linhas. No vídeo https://user-images.githubusercontent.com/10078152/219964798-96dcae76-70e1-44d7-95ca-38d340b181c2.webm aparece isso por volta do minuto 5:00, onde apesar de usar o diff como guia para saber onde fazer as alterações, ainda assim é feita a rápida alternância entre arquivo original e traduzido, para detectar diferenças de conteúdo.

Veja e depois comente. Em última instância, talvez seja necessário retraduzir o arquivo inteiro, linha a linha, para daí ficar sincronizado com o original.

@javiereguiluz Thanks for pointing that out. This patch also likely improves that, because in general this patch will give an improvement if a lot of files are loaded (e.g. web framework files). I'll take that repo into account for future measurements.

goal is preventing SIGPIPE being generated when the peer is no longer alive similar to send with MSG_NOSIGNAL on some platforms.

I submitted a PR to fix the uninitialized accesses. However, this does not get rid of the compile warnings because now the compiler is just not smart enough to see the variables can no longer be used uninitialized.

OK, I now checked the function from_zval_write_uint32() and I think it has nothing to do, if the compiler is smart or not. Definitely, as written above, the additional check [if (ctx->err.has_error)] must be done and till now it lead to UB. So the compiler warning revealed this bug.

Now, the situation changed and I don't think that the compiler can see that the added code fixed a bug and now indeed the variable cannot be accessed uninitialised - due to the new check. Maybe gcc 16 is that smart but there remains always the problem that the function is in another file, so the compiler doesn't have enough information. A conditional meta data informing the compiler when the variable is written could solve the problem but this is something for the future...

I'm closing this, this should be discussed on the list.

Description

All file functions, incl. dir functions like file_exists() or is_dir() return false when the input is empty.

One exception is realpath(), it returns the current directory when '' is given.

The reason is probably the way how realpath() is written, the path is probably checked if absolute and if not, it is appended to the current directory, even if empty.

After a fix, I expect realpath('') to return false.

It is probably not a bug, as documented so [1], but I propose this to be fixed to be consistent with other file functions.

[1] https://github.com/php/doc-en/commit/5ca36de9639a35ba034a93205f4664471f3aae77