At Mon, 9 Mar 2020 17:36:24 +0100, Joerg Sonnenberger wrote:
Subject: Re: NULL pointer arithmetic issues
>
> I consider it as something even worse. Just like the case of passing
> NULL pointers to memcpy and friends with zero as size, this
> interpretation / restriction in
On Mon, Mar 9, 2020 at 2:53 PM Martin Husemann wrote:
>
> On Mon, Mar 09, 2020 at 12:41:37PM -0400, Aaron Ballman wrote:
> > > You could view NULL as a special pointer pointing to an inaccessible
> > > zero sized object. Adding 0 to it still points to the same special
> > > non-object. I guess
On Mon, Mar 09, 2020 at 12:41:37PM -0400, Aaron Ballman wrote:
> > You could view NULL as a special pointer pointing to an inaccessible
> > zero sized object. Adding 0 to it still points to the same special
> > non-object. I guess that is how the C++ folks see it.
>
> This wording has always been
On Mon, Mar 9, 2020 at 12:36 PM Joerg Sonnenberger wrote:
>
> On Mon, Mar 09, 2020 at 09:50:50AM -0400, Aaron Ballman wrote:
> > On Sun, Mar 8, 2020 at 2:30 PM Taylor R Campbell
> > > I ask because in principle a conformant implementation could compile
> > > the NetBSD kernel into a useless blob
On Mon, Mar 9, 2020 at 11:51 AM Martin Husemann wrote:
>
> On Mon, Mar 09, 2020 at 09:38:31AM -0400, Aaron Ballman wrote:
> > The way I read this is:
> >
> > "If the pointer operand points to an element of an array object" -- it
> > does not (null is not a valid array object).
> > "Moreover, if
On Mon, Mar 09, 2020 at 09:50:50AM -0400, Aaron Ballman wrote:
> On Sun, Mar 8, 2020 at 2:30 PM Taylor R Campbell
> > I ask because in principle a conformant implementation could compile
> > the NetBSD kernel into a useless blob that does nothing -- we rely on
> > all sorts of behaviour relative
On Mon, Mar 09, 2020 at 09:38:31AM -0400, Aaron Ballman wrote:
> The way I read this is:
>
> "If the pointer operand points to an element of an array object" -- it
> does not (null is not a valid array object).
> "Moreover, if the expression P points to the last element of an array
> object" --
On Sun, Mar 8, 2020 at 2:30 PM Taylor R Campbell
wrote:
>
> > Date: Sun, 8 Mar 2020 20:52:29 +0300
> > From: Roman Lebedev
> >
> > so we are allowed to lower that in clang front-end as:
> >
> > int
> > statu(char *a)
> > {
> > __builtin_assume(a != NULL);
> > a += getuid() - geteuid();
> >
On Mon, Mar 9, 2020 at 9:21 AM Martin Husemann wrote:
>
> On Mon, Mar 09, 2020 at 01:34:23PM +0100, Kamil Rytarowski wrote:
>
> > We instruct a C compiler that pointer used in the pserialize macros is
> > never NULL, as the side effect of adding to it 0.
>
> I question that side effect.
>
> The
On Mon, Mar 09, 2020 at 01:34:23PM +0100, Kamil Rytarowski wrote:
> We instruct a C compiler that pointer used in the pserialize macros is
> never NULL, as the side effect of adding to it 0.
I question that side effect.
The C++ standard disagrees with your interpration, I have not seen clear
On 09.03.2020 07:05, Martin Husemann wrote:
> Also note that the getuid()/geteuid() example here is IMHO unrelated to the
> original issue that caused this discussion, so I am not even convinced this
> is NOT a ubsan bug.
We instruct a C compiler that pointer used in the pserialize macros is
On Sun, Mar 08, 2020 at 09:58:05PM +0100, Kamil Rytarowski wrote:
> Aaron (as he was mentioned by name), is a voting member in the C++
> committee and actively working on harmonizing C and C++ standards. There
> is a good chance that C and C++ will be synced here (they definitely
> should).
Yes,
On 08.03.2020 19:42, Mouse wrote:
>>> The correct fix is not to disable the null-pointer-check option but
>>> to remove the broken automatic non-null arguments in GCC.
>
>> The C standard and current usage (GNU) disagrees here.
>
> GNU is not some kind of arbiter of "current usage" (whatever
On 08.03.2020 19:30, Taylor R Campbell wrote:
>> Date: Sun, 8 Mar 2020 20:52:29 +0300
>> From: Roman Lebedev
>>
>> so we are allowed to lower that in clang front-end as:
>>
>> int
>> statu(char *a)
>> {
>> __builtin_assume(a != NULL);
>> a += getuid() - geteuid();
>> __builtin_assume(a !=
>> The correct fix is not to disable the null-pointer-check option but
>> to remove the broken automatic non-null arguments in GCC.
> The C standard and current usage (GNU) disagrees here.
GNU is not some kind of arbiter of "current usage" (whatever _that_
means).
> memcpy (along with a number
> Date: Sun, 8 Mar 2020 20:52:29 +0300
> From: Roman Lebedev
>
> so we are allowed to lower that in clang front-end as:
>
> int
> statu(char *a)
> {
> __builtin_assume(a != NULL);
> a += getuid() - geteuid();
> __builtin_assume(a != NULL);
Allowed, yes.
What I'm wondering is whether
Warning: i'm not subscribed to the lists CC'd here.
On Sun, Mar 8, 2020 at 8:26 PM Kamil Rytarowski wrote:
>
> On 08.03.2020 18:00, Taylor R Campbell wrote:
> > Thanks for doing the research.
> >
> >> Date: Sun, 8 Mar 2020 15:30:02 +0100
> >> From: Kamil Rytarowski
> >>
> >> NULL+0 was added to
On 08.03.2020 18:12, Joerg Sonnenberger wrote:
> On Sun, Mar 08, 2020 at 03:33:57PM +0100, Kamil Rytarowski wrote:
>> There was also a request to make a proof that memcpy(NULL,NULL,0) is UB
>> and can be miscompiled.
>>
>> Here is a reproducer:
>>
>> http://netbsd.org/~kamil/memcpy-ub.c
>>
>> 131
On 08.03.2020 18:11, Joerg Sonnenberger wrote:
> On Sun, Mar 08, 2020 at 03:30:02PM +0100, Kamil Rytarowski wrote:
>> NULL+x is now miscompiled by Clang/LLVM after this commit:
>>
>> https://reviews.llvm.org/rL369789
>>
>> This broke various programs like:
>>
>> "Performing base + offset pointer
On 08.03.2020 18:00, Taylor R Campbell wrote:
> Thanks for doing the research.
>
>> Date: Sun, 8 Mar 2020 15:30:02 +0100
>> From: Kamil Rytarowski
>>
>> NULL+0 was added to UBSan proactively as it is as of today not
>> miscompiled, but it is planned to so in not so distant time. It is a
>>
On Sun, Mar 08, 2020 at 03:33:57PM +0100, Kamil Rytarowski wrote:
> There was also a request to make a proof that memcpy(NULL,NULL,0) is UB
> and can be miscompiled.
>
> Here is a reproducer:
>
> http://netbsd.org/~kamil/memcpy-ub.c
>
> 131 kamil@rugged /tmp $ gcc -O0 memcpy.c
>
> 132
On Sun, Mar 08, 2020 at 03:30:02PM +0100, Kamil Rytarowski wrote:
> NULL+x is now miscompiled by Clang/LLVM after this commit:
>
> https://reviews.llvm.org/rL369789
>
> This broke various programs like:
>
> "Performing base + offset pointer arithmetic is only allowed when base
> itself is not
Thanks for doing the research.
> Date: Sun, 8 Mar 2020 15:30:02 +0100
> From: Kamil Rytarowski
>
> NULL+0 was added to UBSan proactively as it is as of today not
> miscompiled, but it is planned to so in not so distant time. It is a
> chicken-egg problem.
If you say it is planned, can you
On 22.02.2020 17:25, Kamil Rytarowski wrote:
> When running the ATF tests under MKLIBCSANITIZER [1], there are many
> NULL pointer arithmetic issues .
>
> http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-null-pointer.txt
>
> These issues are in macros like:
> -
At Wed, 26 Feb 2020 00:12:49 -0500 (EST), Mouse
wrote:
Subject: Re: NULL pointer arithmetic issues
>
> > This is the main point of my original rant. "Undefined Behaviour" as
> > it has been interpreted by Optimization Warriors has given us an
> > unusable langua
Johnny Billquist writes:
> Well, the d-dpace don't start at 1, and also, the PDP-11 isn't that
> fond of odd addresses. :-)
True - I should have said that they started actual allocation of data
objects at a non-zero address. :)
> Here is the current "state":
Thanks! That's really
>>> char *lp = p->s;
>>> if (p == NULL || lp == NULL) {
>> This code is, and always has been, broken; it is accessing p->s
>> before it knows that p isn't nil.
> How do you know for sure?
> What if all calls to foo() are written as such:
> if (p) foo(p);
The code is
> This is the main point of my original rant. "Undefined Behaviour" as
> it has been interpreted by Optimization Warriors has given us an
> unusable language.
I'd say that it's given you unusuable implementations of the language.
The problem is not the language; it's the compiler(s). (Well,
At Mon, 24 Feb 2020 22:15:22 -0500 (EST), Mouse
wrote:
Subject: Re: NULL pointer arithmetic issues
>
> > Greg A. Woods wrote:
> >
> > NO MORE "undefined behaviour"!!! Pick something sane and stick to it!
> >
> > The problem with mode
On 2020-02-25 12:33, Tom Ivar Helbekkmo wrote:
Johnny Billquist writes:
But yes, on the PDP11 [having nothing mapped at address 0] was/is not
the case. Memory space is too precious to allow some of it to be
wasted for this...
Yup - and I assume the "hack" Kamil alludes to is the practice of
Johnny Billquist writes:
> But yes, on the PDP11 [having nothing mapped at address 0] was/is not
> the case. Memory space is too precious to allow some of it to be
> wasted for this...
Yup - and I assume the "hack" Kamil alludes to is the practice of
actually starting the data segment for split
> I wrote the following rant some time ago and posted it somewhere
> I'll throw it in here for some more fuel
> NO MORE "undefined behaviour"!!! Pick something sane and stick to it!
> The problem with modern "Standard" C is that instead of refining
> the definition of the abstract
e hardware systems where "null"
pointers are not actually all zeros in the hardware. I hope to be one.
At Mon, 24 Feb 2020 14:41:26 +0100, Kamil Rytarowski wrote:
Subject: Re: NULL pointer arithmetic issues
>
> Please join the C committee as a voting member or at least submit papers
&
> Date: Mon, 24 Feb 2020 11:42:01 +0100
> From: Kamil Rytarowski
>
> Forbidding NULL pointer arithmetic is not just for C purists trolls. It
> is now in C++ mainstream and already in C2x draft.
>
> The newer C standard will most likely (already accepted by the
> committee) adopt nullptr on par
>> int one(void) { return(1); }
>> then (one()-one()) is not [a null pointer constant]
> As you say, it's an integer expression. And I read that "or" part as
> just an expression, which this is. So I believe it is a valid way to
> creating something that can be converted to a NULL pointer.
C99
On 2020-02-25 02:12, Mouse wrote:
Oh. And I actually do not believe it has to be a constant.
You are correct; it does not need to be a simple constant.
The text says "integer constant expression with the value 0, or such
an expression..."
Yes. (void *)(1-1) is a valid null pointer
> Oh. And I actually do not believe it has to be a constant.
You are correct; it does not need to be a simple constant.
> The text says "integer constant expression with the value 0, or such
> an expression..."
Yes. (void *)(1-1) is a valid null pointer constant. So, on an
all-ASCII system,
On Mon, Feb 24, 2020 at 05:35:22PM -0500, Mouse wrote:
> > Unless I remember wrong, older C standards explicitly say that the
> > integer 0 can be converted to a pointer, and that will be the NULL
> > pointer, and a NULL pointer cast as an integer shall give the value
> > 0.
>
> The only one I
> On Feb 24, 2020, at 4:08 PM, Kamil Rytarowski wrote:
>
> NULL in C is expected to be harmonized with nullptr from C++.
This is insanity. C++ is a cesspit where dreams of elegant code go to die.
-- thorpej
...proud owner of a "C++ Barf Bag" that hangs outside his office...
On 24.02.2020 23:35, Mouse wrote:
>> Unless I remember wrong, older C standards explicitly say that the
>> integer 0 can be converted to a pointer, and that will be the NULL
>> pointer, and a NULL pointer cast as an integer shall give the value
>> 0.
>
> The only one I have anything close to a
On 2020-02-24 21:24, Kamil Rytarowski wrote:
On 24.02.2020 21:18, Mouse wrote:
If we use 0x0, it can be a valid pointer.
If we use NULL, it's not expected to work and will eventually
generate a syntax erro.
Then someone has severely broken compatability with older versions of
C. 0x0 and
On 2020-02-25 00:24, Johnny Billquist wrote:
On 2020-02-24 23:35, Mouse wrote:
Unless I remember wrong, older C standards explicitly say that the
integer 0 can be converted to a pointer, and that will be the NULL
pointer, and a NULL pointer cast as an integer shall give the value
0.
The only
On 2020-02-24 23:35, Mouse wrote:
Unless I remember wrong, older C standards explicitly say that the
integer 0 can be converted to a pointer, and that will be the NULL
pointer, and a NULL pointer cast as an integer shall give the value
0.
The only one I have anything close to a copy of is C99,
On 2020-02-24 21:18, Mouse wrote:
If we use 0x0, it can be a valid pointer.
If we use NULL, it's not expected to work and will eventually
generate a syntax erro.
Then someone has severely broken compatability with older versions of
C. 0x0 and (when one of the suitable #includes has been
> Unless I remember wrong, older C standards explicitly say that the
> integer 0 can be converted to a pointer, and that will be the NULL
> pointer, and a NULL pointer cast as an integer shall give the value
> 0.
The only one I have anything close to a copy of is C99, for which I
have a very late
If we use 0x0, it can be a valid pointer.
If we use NULL, it's not expected to work and [...]
>> Then someone has severely broken compatability with older versions
>> of C. [...]
> The process of evaluation of the NULL semantics is not a recent
> thing.
No, it's not. But I was talking
Kamil Rytarowski wrote:
>We still maintain compatibility with this behavior (originated as a hack
>in PDP11) in older NetBSD releases (NetBSD-0.9 Franz Lisp binaries
>depend on this).
I presume this was built for NetBSD/vax.
A 68k build of Franz Lisp wouldn't try to dereference a NULL
On 24.02.2020 21:18, Mouse wrote:
>>> If we use 0x0, it can be a valid pointer.
>
>>> If we use NULL, it's not expected to work and will eventually
>>> generate a syntax erro.
>
> Then someone has severely broken compatability with older versions of
> C. 0x0 and (when one of the suitable
>> If we use 0x0, it can be a valid pointer.
>> If we use NULL, it's not expected to work and will eventually
>> generate a syntax erro.
Then someone has severely broken compatability with older versions of
C. 0x0 and (when one of the suitable #includes has been done) NULL
have both
> > Nonsense, I think it's fair to classify that as a bug. That sort of
> > stuff is *not* supposed to happen if -ffreestanding is passed to the
> > compiler.
>
> If we use 0x0, it can be a valid pointer.
>
> If we use NULL, it's not expected to work and will eventually generate a
> syntax
In article ,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 24.02.2020 13:41, Joerg Sonnenberger wrote:
>> On Mon, Feb 24, 2020 at 11:42:01AM +0100, Kamil Rytarowski wrote:
>>> Forbidding NULL pointer arithmetic is not just for C purists trolls. It
>>> is now in C++ mainstream and
On 24.02.2020 15:35, Don Lee wrote:
>
>> On Feb 24, 2020, at 8:05 AM, Mouse wrote:
>>
> RUST is better defined that C and is indeed used in OS development
> these days
...so? I don't see how this is related to the rest of the
discussion.
>>> As C is considered as not suitable
> On Feb 24, 2020, at 8:05 AM, Mouse wrote:
>
RUST is better defined that C and is indeed used in OS development
these days
>>> ...so? I don't see how this is related to the rest of the
>>> discussion.
>> As C is considered as not suitable for OS development,
>
> Once again, there
On 24.02.2020 15:04, Jason Thorpe wrote:
>
>> On Feb 24, 2020, at 4:22 AM, Kamil Rytarowski wrote:
>>
>> A compiler once being smart enough can introduce ILL/SEGV traps into
>> code that performs operations on NULL pointers. This already bitten us
>> when we were registering a handler at address
> On Feb 24, 2020, at 4:22 AM, Kamil Rytarowski wrote:
>
> A compiler once being smart enough can introduce ILL/SEGV traps into
> code that performs operations on NULL pointers. This already bitten us
> when we were registering a handler at address 0x0 for the kernel code,
> GCC changed the
>> C is not a language. C is a family of closely related languages.
>> Some of them are suitable for OS implementation. It appears some of
>> the more recent ones are not, but this does not mean the older ones
>> also aren't.
> From my perception the trend is inversed. Things that were
On 24.02.2020 14:03, Mouse wrote:
It is now in C++ mainstream and already in C2x draft.
>>> Then those are not suitable languages for OS implementations.
>> This battle is lost for C
>
> C is not a language. C is a family of closely related languages.
>
If we tread C as gnu89 gnu99 gnu11
On 24.02.2020 13:41, Joerg Sonnenberger wrote:
> On Mon, Feb 24, 2020 at 11:42:01AM +0100, Kamil Rytarowski wrote:
>> Forbidding NULL pointer arithmetic is not just for C purists trolls. It
>> is now in C++ mainstream and already in C2x draft.
>
> This is not true. NULL pointer arithmetic and
>>> It is now in C++ mainstream and already in C2x draft.
>> Then those are not suitable languages for OS implementations.
> This battle is lost for C
C is not a language. C is a family of closely related languages.
Some of them are suitable for OS implementation. It appears some of
the more
On Mon, Feb 24, 2020 at 11:42:01AM +0100, Kamil Rytarowski wrote:
> Forbidding NULL pointer arithmetic is not just for C purists trolls. It
> is now in C++ mainstream and already in C2x draft.
This is not true. NULL pointer arithmetic and nullptr arithmetic are
*very* different things. Do not
On 24.02.2020 12:14, Mouse wrote:
>> Forbidding NULL pointer arithmetic is not just for C purists trolls.
>> It is now in C++ mainstream and already in C2x draft.
>
> Then those are not suitable languages for OS implementations.
>
> I'm with campbell and mrg on this one. It is not appropriate
> Forbidding NULL pointer arithmetic is not just for C purists trolls.
> It is now in C++ mainstream and already in C2x draft.
Then those are not suitable languages for OS implementations.
I'm with campbell and mrg on this one. It is not appropriate to twist
NetBSD's code into a pretzel to work
On 24.02.2020 05:03, Taylor R Campbell wrote:
>> Date: Sun, 23 Feb 2020 22:51:08 +0100
>> From: Kamil Rytarowski
>>
>> On 23.02.2020 20:08, Taylor R Campbell wrote:
>> Date: Sun, 23 Feb 2020 22:51:08 +0100
>> From: Kamil Rytarowski
>>
>> On 23.02.2020 20:08, Taylor R Campbell wrote:
Date:
> It seems to me the proper approach is to teach the tool to accept
> this, and to avoid cluttering the tree with churn to work around the
> tool's deficiency, unless there's actually a serious compelling
> argument -- beyond a language-lawyering troll -- that (char *)NULL + 0
> is meaningfully
> Date: Sun, 23 Feb 2020 22:51:08 +0100
> From: Kamil Rytarowski
>
> On 23.02.2020 20:08, Taylor R Campbell wrote:
> Date: Sun, 23 Feb 2020 22:51:08 +0100
> From: Kamil Rytarowski
>
> On 23.02.2020 20:08, Taylor R Campbell wrote:
> >> Date: Sat, 22 Feb 2020 17:25:42 +0100
> >> From: Kamil
On 23.02.2020 20:08, Taylor R Campbell wrote:
>> Date: Sat, 22 Feb 2020 17:25:42 +0100
>> From: Kamil Rytarowski
>>
>> When running the ATF tests under MKLIBCSANITIZER [1], there are many
>> NULL pointer arithmetic issues .
>>
>>
> Date: Sat, 22 Feb 2020 17:25:42 +0100
> From: Kamil Rytarowski
>
> When running the ATF tests under MKLIBCSANITIZER [1], there are many
> NULL pointer arithmetic issues .
>
> http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-null-pointer.txt
>
> These issues are in macros like:
>
On 22.02.2020 19:39, Joerg Sonnenberger wrote:
> On Sat, Feb 22, 2020 at 05:25:42PM +0100, Kamil Rytarowski wrote:
>> When running the ATF tests under MKLIBCSANITIZER [1], there are many
>> NULL pointer arithmetic issues .
>
> Which flags are the sanitizers using? Because I wouldn't be surprised
On Sat, Feb 22, 2020 at 05:25:42PM +0100, Kamil Rytarowski wrote:
> When running the ATF tests under MKLIBCSANITIZER [1], there are many
> NULL pointer arithmetic issues .
Which flags are the sanitizers using? Because I wouldn't be surprised if
they just hit _PSLIST_VALIDATE_PTRS and friends.
69 matches
Mail list logo
