Closed Bug 1164602 Opened 4 years ago Closed 4 years ago

Replace NullPtr hack with nullptr_t


(Core :: JavaScript: GC, defect)

Not set



Tracking Status
firefox41 --- fixed


(Reporter: terrence, Assigned: terrence)


(Blocks 2 open bugs)



(1 file, 1 obsolete file)

When we implemented Handle, nullptr_t was still a typedef to 0 on some platforms. Now that it is a real thing everywhere, we should be able to replace our NullPtr workaround with a constructor taking std::nullptr_t. The only remaining issue is that some platforms do not have a modern libstdc++, so do not have std::nullptr_t. Luckily we can get around that by using decltype(nullptr) instead. This patch appears to work locally; try run is below to check the other platforms:

The attached patch was generated with:
$ find . -name "*.cpp" -o -name "*.h" -exec sed -i 's/JS::NullPtr()/nullptr/g' \{\} \;
$ find . -name "*.cpp" -o -name "*.h" -exec sed -i 's/js::NullPtr()/nullptr/g' \{\} \;
$ find . -name "*.cpp" -o -name "*.h" -exec sed -i 's/NullPtr()/nullptr/g' \{\} \;

With a bit of hand tweaking afterwards to fix up and JS::GCCellPtr::NullPtr.
Whoops! Forgot that the null needs to be at the second level of indirection. Easy enough to solve.
Attachment #8605433 - Attachment is obsolete: true
Attachment #8605513 - Flags: review?(sphink)
Comment on attachment 8605513 [details] [diff] [review]

Review of attachment 8605513 [details] [diff] [review]:

::: js/public/RootingAPI.h
@@ +120,5 @@
>  template <typename T>
>  class PersistentRootedBase {};
> +static void*const ConstNullValue = nullptr;

static void* const ConstNullValue = nullptr;

assuming this is still needed?

@@ +407,3 @@
>          static_assert(mozilla::IsPointer<T>::value,
> +                      "nullptr_t overload not valid for non-pointer types");
> +        ptr = reinterpret_cast<const T*>(&js::ConstNullValue);

Wouldn't this be better with just a static nullptr declared right here? Or do we compare these pointers somehow?
Attachment #8605513 - Flags: review?(sphink) → review+
InternalHandle's constructor also needed an &nullptr and I thought it would be simpler to share them. I mean, it would be weird for null handle != null handle, even if we never actually use the feature.
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.