On 28/07/2023 21:51, Thorsten Glaser via austin-group-l at The Open
Group wrote:
Davin McCall via austin-group-l at The Open Group dixit:
Since the operand isn't evaluated, there is no null pointer dereference. It is
That’s what I told them, but they weren’t convinced.
This has been
On 29/7/23 6:51 am, Thorsten Glaser wrote:
If the type of the operand is a variable length array type, the
operand is evaluated; otherwise, the operand is not evaluated and the
Yeah ouch, so it can easily become UB even here already…
I do not believe so, since the relevant field is not (and
Davin McCall via austin-group-l at The Open Group dixit:
> Since the operand isn't evaluated, there is no null pointer dereference. It is
That’s what I told them, but they weren’t convinced.
> If the type of the operand is a variable length array type, the
> operand is evaluated; otherwise, the
On 22/7/23 12:22 pm, Thorsten Glaser via austin-group-l at The Open
Group wrote:
https://www.austingroupbugs.net/view.php?id=561#c6085 (the accepted
text) suggests that…
versions, the size is typically in the range 92 to 108. An
application can
deduce the size by using
Thorsten Glaser wrote in
:
|https://www.austingroupbugs.net/view.php?id=561#c6085 (the accepted
|text) suggests that…
|
| versions, the size is typically in the range 92 to 108. An \
| application can
| deduce the size by using sizeof(((struct sockaddr_un *)0)->sun_pat\
|
https://www.austingroupbugs.net/view.php?id=561#c6085 (the accepted
text) suggests that…
versions, the size is typically in the range 92 to 108. An application
can
deduce the size by using sizeof(((struct sockaddr_un
*)0)->sun_path).
… but I was recently told that attempting that
