unsafeUseAsCString(Len) may return a NULL pointer.

[phadej]

Prelude Data.ByteString Data.ByteString.Unsafe> unsafeUseAsCStringLen mempty print
(0x0000000000000000,0)
Prelude Data.ByteString Data.ByteString.Unsafe> unsafeUseAsCStringLen "" print
(0x0000004200439cf0,0)

While generally this behavior is fine, it probably should be documented, as it might surprise someone (it did surprise me).

In haskellari/postgresql-libpq#54, libpq differentiates between NULL pointer, and a pointer with data length zero.

[clyring]

There is already a remark on this in the docstring for unsafeUseAsCStringLen: If 'Data.ByteString.empty' is given, it will pass @('Foreign.Ptr.nullPtr', 0)@.

I'm not sure there's much more that can reasonably be done here. But feel free to re-open if you have ideas.

[phadej]

It's on unsafeUseAsCStringLen but the remark is not on unsafeUseAsCString

There is a shared remark, and different ones. It's hard to know which ones are actually shared (all of them, none?). The documentation is not clear there.

[clyring]

Ah. And yet remarking about empty with unsafeUseAsCString would seem a bit off since that's already very likely wrong for null-termination reasons.

[phadej]

And yet remarking about empty with unsafeUseAsCString would seem a bit off since that's already very likely wrong for null-termination reasons.

Why? unsafeUseAsCString doesn't do any null-termination, does it?

[clyring]

Yes, exactly. unsafeUseAsCString doesn't add any null-termination, and the empty bytestring can't be expected to be null-terminated.

[phadej]

But i'm not talking about null-termination, I'm talking that the pointer itself returned may be NULL.

I expect to see

-- If 'Data.ByteString.empty' is given, it will pass @'Foreign.Ptr.nullPtr'@.

for unsafeUseAsCString, or a shared comment in Using ByteStrings with functions for CStrings section

---

Also is it then a bug that unsafeUseAsCStringLen "" print doesn't give me a null pointer?

[clyring]

I mean that a call unsafeUseAsCString empty someFunctionExpectingCString is already very suspicious because it will pass a pointer to a buffer that isn't null-terminated to someFunctionExpectingCString.

Also is it then a bug that unsafeUseAsCStringLen "" print doesn't give me a null pointer?

We make no guarantees about what underlying pointer is used in the empty result of packChars "".

[phadej]

is already very suspicious because it will pass a pointer to a buffer that isn't null-terminated to

it might be, but it's irrelevant to this documentation issue. (The code I work one calls Data.ByteString.length elsewhere, so C code is called with length, it just doesn't get it from unsafeUseAsCString*.

[phadej]

We make no guarantees about what underlying pointer is used in the empty result of packChars "".

Then the remark about empty should be further clarified, as there is a difference between empty and packChars "". Some values are equivalent to empty, and some aren't (and again, it's hard to say whether that is a bug or conscious decision). Another example is copy empty.