I'll post a patch this morning. If a library sees a version "from the
future" it should error, pretty simple.
On Tue, Jul 14, 2020 at 8:47 AM Antoine Pitrou wrote:
>
>
> Le 14/07/2020 à 15:46, Micah Kornfield a écrit :
> > I think allowing out of range values would be a mistake. Doesn't a change
Le 14/07/2020 à 15:46, Micah Kornfield a écrit :
> I think allowing out of range values would be a mistake. Doesn't a change
> in the metadata version indicates a non backwards compatible change?
I have no idea. Perhaps it will indeed, especially now that we have the
features enum.
Regards
A
I think allowing out of range values would be a mistake. Doesn't a change
in the metadata version indicates a non backwards compatible change?
On Tuesday, July 14, 2020, Antoine Pitrou wrote:
>
> I think Micah is right. Also, it seems (from checking the source) that
> the Flatbuffers verifier
I think Micah is right. Also, it seems (from checking the source) that
the Flatbuffers verifier doesn't check that enums are in range, so we
may possibly allow out-of-range values and interpret them as "highest
supported version".
Regards
Antoine.
Le 14/07/2020 à 00:53, Micah Kornfield a écr
Thanks Micah. I'll check in the test file that has the V6 metadata and
open a PR later today
On Mon, Jul 13, 2020 at 5:53 PM Micah Kornfield wrote:
>
> To clarify on UBSAN and enums. My understanding is:
>
> enum A { a = 1, b =2, c = 3};
> class enum B : int16_t { a = 1, b = 2, c = 3};
>
> A a =
To clarify on UBSAN and enums. My understanding is:
enum A { a = 1, b =2, c = 3};
class enum B : int16_t { a = 1, b = 2, c = 3};
A a = static_cast(4); // UB
B b = static_cast(4); // Not UB. Declaring the holding type makes this
allowable.
On Mon, Jul 13, 2020 at 3:44 PM Micah Kornfield
wrote
Please see [1]. I ran this arrow-ipc-read-write-test with UBSAN enabled
and it passed (this isn't my normal dev environment so please double check).
https://github.com/emkornfield/arrow/commit/7fbd0fb95f7ea164284720428c7974b87b4b2443
On Mon, Jul 13, 2020 at 3:12 PM Micah Kornfield
wrote:
> I
I think this might be more complicated, let me see if i can write a test
that demonstrates what I'm talking about.
On Mon, Jul 13, 2020 at 3:10 PM Wes McKinney wrote:
> Here's a patch that does the check
>
>
> https://github.com/wesm/arrow/commit/5bfdb4255a66a4ec62b1c36ba07682fad47df9a7
>
> Here
Here's a patch that does the check
https://github.com/wesm/arrow/commit/5bfdb4255a66a4ec62b1c36ba07682fad47df9a7
Here is a serialized schema that uses a V6 version
https://drive.google.com/file/d/1GiWh5yKXdMaLRWU5K4cnGW2ilybF0LF_/view?usp=sharing
See in action https://gist.github.com/wesm/f9621
On Mon, Jul 13, 2020 at 4:43 PM Micah Kornfield wrote:
>>
>> We don't have any test cases that have a future metadata version. I
>> made a branch where I added V6 and wrote an IPC message, then found
>> that I was unable to determine that it was out of bounds (presumably
>> UBSAN would error, thou
>
> We don't have any test cases that have a future metadata version. I
> made a branch where I added V6 and wrote an IPC message, then found
> that I was unable to determine that it was out of bounds (presumably
> UBSAN would error, though, but we need a runtime error outside of
> ASAN/UBSAN).
To
On Mon, Jul 13, 2020 at 4:31 PM Micah Kornfield wrote:
>
> >
> >
> > That static cast is currently undefined behavior.
>
> Is ubsan reporting this? When looking into the feature enum I tried to
> understand if that was valid. At the time I read the C++ spec* if the enum
> has an explicitly declar
>
>
> That static cast is currently undefined behavior.
Is ubsan reporting this? When looking into the feature enum I tried to
understand if that was valid. At the time I read the C++ spec* if the enum
has an explicitly declared type, all values in that types range are
supported.
The generated e
I've discovered while working on ARROW-9399 that it is very difficult
with the Flatbuffers API in C++ to detect a MetadataVersion [1] that
is higher than the current version.
For example, suppose that 3 or 4 years from now we move from version
V5 to version V6. The generated Flatbuffers code looks
14 matches
Mail list logo
