Am Mo., 3. Feb. 2025 um 22:40 Uhr schrieb Jerry James <loganjerry@xxxxxxxxx>:
>
> On Mon, Feb 3, 2025 at 2:22 PM Michael J Gruber <mjg@xxxxxxxxxxxxxxxxx> wrote:
> > So, over at upstream they raised the suspicion that some parts of what
> > I'm linking are compiled with different flags. To recap: I get
> > ```
> > /usr/include/c++/15/bits/stl_vector.h:1262: std::vector<_Tp,
> > _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type)
> > [with _Tp = const char*; _Alloc = std::allocator<const char*>;
> > reference = const char*&; size_type = long unsigned int]: Assertion
> > '__n < this->size()' failed.
> > Aborted (core dumped)
> > ```
> > in a part of code which basically does:
> > ```
> > FZ_FUNCTION std::vector<std::string>
> > pdf_choice_widget_options2(fz_context* ctx, pdf_annot* tw, int
> > exportval)
> > {
> > int n = pdf_choice_widget_options(ctx, tw, exportval, nullptr);
> > std::vector<const char*> opts(n);
> > int n2 = pdf_choice_widget_options(ctx, tw, exportval, &opts[0]);
> > assert(n2 == n);
> > std::vector<std::string> ret(n);
> > for (int i=0; i<n; ++i)
> > {
> > ret[i] = opts[i];
> > }
> > return ret;
> > }
> > ```
> > Is there anything regarding flags like NDEBUG, GLIBCXX_ASSERTIONS and
> > the like which could make the above throw when the .so is compiled
> > with different flags compared to the code that calls it? Something
> > that appeared with gcc15 or libstdc++ in gcc15?
>
> If n == 0, then &opts[0] is invalid, since opts is an empty vector in
> that case. The invalid access to the nonexistent zeroth element
> triggers an assertion failure inside operator[] when the code is
> compiled with -D_GLIBCXX_ASSERTIONS.
> --
Thanks! I had stumbled upon &opts[0] before, but my poor C
programmer's mind converted that to opts (as in arrays refs "are"
pointers) and expected the c++ compiler to do the same, when indeed it
is different (for an empty vector with zero elements). I converted
this to opts.data() now, and the first mock build in f42 works.
Hooray!
Cheers
Michael
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
