hi Krisztian,

This is a tricky problem. This has come up in other circumstances as I
recall, I can't remember specifically where.

In the case of Buffers, we could possibly avoid having a
shared_ptr<Buffer>(nullptr) issue by creating a "dummy" zero-length
buffer with a valid memory address for its data. This wouldn't prevent
the case where some code has created a Buffer(nullptr, 0) elsewhere
(so an instance of Buffer has been allocated, but its internal data_
member is null).

One way to alleviate the pain (without adding code to ensure that
either a buffer or its data_ member is never null) might be to have
some helper methods like


though I think this function needs a nullptr check also (just created
https://issues.apache.org/jira/browse/ARROW-2708 to look into it)

- Wes

On Fri, Jun 1, 2018 at 5:40 AM, Krisztián Szűcs
<szucs.kriszt...@gmail.com> wrote:
> Hi Everyone,
> Recently I've investigated a parquet edge case ARROW-2591 which is caused by 
> a returned nullptr here. 
> (https://link.getmailspring.com/link/1527842287.local-dc8ae776-35fa-v1.2.2-96fb3...@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fapache%2Fparquet-cpp%2Fblob%2Fmaster%2Fsrc%2Fparquet%2Farrow%2Fwriter.cc%23L415&recipient=ZGV2QGFycm93LmFwYWNoZS5vcmc%3D)
> I'm wondering would it be possible to avoid having nullptrs instead of 
> checking them?
> IMHO having them around causes hidden bugs as well as increases the 
> complexity.
> Krisztian

Reply via email to