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 https://github.com/apache/arrow/blob/master/cpp/src/arrow/compute/kernels/util-internal.h#L33 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
