Re: [libc-coord] Re: Expose 'array_length()' macro in or

[enh via Gcc]

Why would C++ programmers need this given
https://en.cppreference.com/w/cpp/iterator/size ?

On Mon, Sep 21, 2020, 05:54 Alejandro Colomar 
wrote:

> [[ CC += libc-coord at lists.openwall.com ]]
>
> On 2020-09-21 12:33, Florian Weimer wrote:
> > * Alejandro Colomar:
> >
> >> [[
> >> CC += libc-coord at sourceware.org
> >> CC += gcc at gcc.gnu.org
> >> CC += libstdc++ at gcc.gnu.org
> >> ]]
> >>
> >> Hi Florian,
> >>
> >> On 2020-09-21 10:38, Florian Weimer wrote:
> >>> * Alejandro Colomar via Libc-alpha:
> >>>
>  I'd like to propose exposing the macro 'array_length()' as defined in
>  'include/array_length.h' to the user.
> >>>
> >>> It would need a good C++ port, probably one for C++98 and another one
> >>> for C++14 or later.
> >>
> >> For C++, I use the following definition:
> >>
> >>
> >>  #include 
> >>  #include 
> >>  #include 
> >>
> >>
> >>  #define is_array__(a)   (std::is_array <__typeof__(a)>::value)
> >
> > Should be decltype.
>
> Thanks.
>
> >
> >> However, there are a few problems:
> >>
> >> 1) This doesn't work for VLAs (GNU extension).
> >> I couldn't find a way to do it.  Maybe I should file a bug in GCC.
> >
> > I do not think VLA support is critical.  C++ programmers will be used to
> > limited support in utility functions.
> >
> >> 2) Also, this requires C++11; I don't know how to do it for older C++.
> >> Again, support from the compiler would be great.
> >
> > I think limited C++98 support is possible using a function template,
> > where the array length N is a template parameter.  To enable use in
> > constant expressions, you can return a type of char[N], and the macro
> > wrapper should then apply sizeof to the function result.
>
> Sorry, I don't know much C++, and I don't know how to do this.
>
> >
> >> 3) The macro can't be used in the same places as the C version,
> >> because of the `({})`.
> >> The `0 * sizeof(struct{...})` trick doesn't work in C++ due to:
> >>  error: types may not be defined in 'sizeof' expressions
> >
> > For C++11, you can use a constexpr function instead of a macro.
> >
> > array_length should not be a macro in current C++ modes, so that we
> > retain compatibility if a future C++ standard adds array_length (or
> > nitems) on its own.  This is not a concern for legacy C++98 mode.
>
> See above.
>
> >
> >>> Maybe also ask on the libc-coord list.
> >>
> >> Ok.  Added CCs.
> >
> > libc-coord is not hosted on sourceware:
> >
> >
> >
> > The discussion here veered off into C++ territory anyway.
>
> I added the correct list now.
>
> >
> > Thanks,
> > Florian
> >
>
> Thanks,
>
> Alex.
>

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[enh via Gcc]

(Android libc maintainer.)

should __memcmpeq be in compiler-rt rather than libc?

On Thu, Sep 16, 2021 at 1:35 PM Joseph Myers 
wrote:

> On Thu, 16 Sep 2021, Chris Kennelly wrote:
>
> > In terms of relying on the feature:  If __memcmpeq is ever exposed as an
> a
> > simple alias for memcmp (since the notes mention that it's a valid
> > implementation), does that open up the possibility of depending on the
> > bcmp-like behavior that we were trying to escape?
>
> The proposal is as an ABI only (compilers would generate calls to
> __memcmpeq from boolean uses of memcmp, users wouldn't write calls to
> __memcmpeq directly, __memcmpeq wouldn't be declared in installed libc
> headers).  If such dependence arises, that would suggest a compiler bug
> wrongly generating such calls for non-boolean memcmp uses.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

[enh via Gcc]

plus testing for _equality_ can (as mentioned earlier) have slightly
different properties from the three-way comparator behavior of
bcmp()/memcmp().

On Thu, Sep 16, 2021 at 2:43 PM Joseph Myers 
wrote:

> On Thu, 16 Sep 2021, James Y Knight wrote:
>
> > Wouldn't it be far simpler to just un-deprecate bcmp?
>
> The aim is to have something to which calls can be generated in all
> standards modes.  bcmp has never been part of ISO C; there's nothing to
> undeprecate there.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h)

[enh via Gcc]

(bionic maintainer here, mostly by accident...)

yeah, we tried the GCC attributes once before with _disastrous_
results (because GCC saw it as an excuse to delete explicit null
checks, it broke all kinds of things). the clang attributes are
"better" in that they don't confuse two entirely separate notions ...
but they're not "good" because the analysis is so limited. i think we
were hoping for something more like the "used but not set" kind of
diagnostic, but afaict it really only catches _direct_ use of a
literal nullptr. so:

  foo(nullptr); // caught

  void* p = nullptr;
  foo(p); // not caught

without getting on to anything fancy like:

  void* p;
  if (a) p = bar();
  foo(p);

we've done all the annotations anyway, but we're not expecting to
actually catch many bugs with them, and in fact did not catch any real
bugs in AOSP while adding the annotations. (though we did find several
"you're not _wrong_, but ..." bits of code :-) )

what i really want for christmas is the annotation that lets me say
"this size_t argument tells you the size of this array argument" and
actually does something usefully fortify-like with that. i've seen
proposals like 
https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/
but i haven't seen anything i can use yet, so you -- who do use GCC
which aiui has something along these lines already -- will find out
what's good/bad about it before i do...

On Tue, Aug 8, 2023 at 3:01 AM Martin Uecker  wrote:
>
> Am Montag, dem 10.07.2023 um 22:16 +0200 schrieb Alejandro Colomar via Gcc:
> > On 7/10/23 22:14, Alejandro Colomar wrote:
> > > [CC += Andrew]
> > >
> > > Hi Xi, Andrew,
> > >
> > > On 7/10/23 20:41, Xi Ruoyao wrote:
> > > > Maybe we should have a weaker version of nonnull which only performs the
> > > > diagnostic, not the optimization.  But it looks like they hate the idea:
> > > > https://gcc.gnu.org/PR110617.
> > > >
> > > This is the one thing that makes me use both Clang and GCC to compile,
> > > because while any of them would be enough to build, I want as much
> > > static analysis as I can get, and so I want -fanalyzer (so I need GCC),
> > > but I also use _Nullable (so I need Clang).
> > >
> > > If GCC had support for _Nullable, I would have in GCC the superset of
> > > features that I need from both in a single vendor.  Moreover, Clang's
> > > static analyzer is brain-damaged (sorry, but it doesn't have a simple
> > > command line to run it, contrary to GCC's easy -fanalyzer), so having
> > > GCC's analyzer get over those _Nullable qualifiers would be great.
> > >
> > > Clang's _Nullable (and _Nonnull) are not very useful outside of analyzer
> > > mode, as there are many cases where the compiler doesn't have enough
> > > information, and the analyzer can get rid of false negatives and
> > > positives.  See: 
> > >
> > > I'll back the ask for the qualifiers in GCC, for compatibility with
> > > Clang.
> >
> > BTW, Bionic libc is adding those qualifiers:
> >
> > 
> > 
> >
> >
>
> I am sceptical about these qualifiers because they do
> not fit well with this language mechanism.   Qualifiers take
> effect at accesses to objects and are discarded at lvalue
> conversion.  So a qualifier should ideally describe a property
> that is relevant for accessing objects but is not relevant
> for values.
>
> Also there are built-in conversion rules a qualifier should
> conform to.  A pointer pointing to a type without qualifier
> can implicitely convert to a pointer to a type with qualifier,
> e.g.   int*  can be converted to const int*.
>
> Together, this implies that a qualifier should add constraints
> to a type that are relevant to how an object is accessed.
>
> "const" and "volatile" or "_Atomic" are good examples.
> ("restricted" does not quite follow these rules and is
> considered weird and difficult to understand.)
>
> In contrast, "nonnull" and "nullable" are properties that
> affect the set of values of the pointer, but not how the
> pointer itself is accessed.
>
>
> Martin
>
>
>
>
>

Re: _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h)

[enh via Gcc]

On Wed, Aug 9, 2023 at 12:26 AM Martin Uecker  wrote:
>
> Am Dienstag, dem 08.08.2023 um 17:14 -0700 schrieb enh:
> > (bionic maintainer here, mostly by accident...)
> >
> > yeah, we tried the GCC attributes once before with _disastrous_
> > results (because GCC saw it as an excuse to delete explicit null
> > checks, it broke all kinds of things).
>
> Thanks! I am currently exploring different options and what
> could be done to improve the situation from the language
> as well as compile side.  It looks we have some partial
> solution but they do not work quite right or do not
> fit together perfectly.
>
>
> >  the clang attributes are
> > "better" in that they don't confuse two entirely separate notions ...
> > but they're not "good" because the analysis is so limited. i think we
> > were hoping for something more like the "used but not set" kind of
> > diagnostic, but afaict it really only catches _direct_ use of a
> > literal nullptr. so:
> >
> >   foo(nullptr); // caught
> >
> >   void* p = nullptr;
> >   foo(p); // not caught
> >
> > without getting on to anything fancy like:
> >
> >   void* p;
> >   if (a) p = bar();
> >   foo(p);
> >
> > we've done all the annotations anyway, but we're not expecting to
> > actually catch many bugs with them, and in fact did not catch any real
> > bugs in AOSP while adding the annotations. (though we did find several
> > "you're not _wrong_, but ..." bits of code :-) )
> >
> > what i really want for christmas is the annotation that lets me say
> > "this size_t argument tells you the size of this array argument" and
> > actually does something usefully fortify-like with that.
> >
>
> What is your opinion about the access attribute?
>
> https://godbolt.org/z/PPfajefvP
>
> it is a bit cumbersome to use, but one can use [static]
> instead, which gives you the same static warnings.

yeah, "that's hard to read" was actually my first reaction. maybe it's
just because i'm a libc maintainer used to the printf_like attribute,
but i actually find the regular __attribute__() style more readable.
you probably need to ask people who _consume_ more headers than they
write :-)

> [static] does not work with __builtin_dynamic_object_size,
> but maybe this could be changed (there is a bug filed.)
>
> I am not sure whether [static] should imply [[gnu::nonnull]]
> which would then also trigger the optimization. I think
> clang uses it for optimization.

yeah, that was what made us revert the old gcc nonnull annotations ---
we don't have any use case for "please use this to omit checks"
because we're generally dealing with public API. having the compiler
dead-code eliminate our attempts to return sensible errors was counter
to our goals, and seems like it would be in any place where we'd use a
bounds annotation too --- it'll be those worried about security (who
want to fail fast, and _before_ adding a potentially caller-controlled
index to an array base address!) who i'd expect to see using this kind
of thing first.

> Martin
>
>
> >  i've seen
> > proposals like 
> > https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/
> > but i haven't seen anything i can use yet, so you -- who do use GCC
> > which aiui has something along these lines already -- will find out
> > what's good/bad about it before i do...
>
>
>
> >
> > On Tue, Aug 8, 2023 at 3:01 AM Martin Uecker  wrote:
> > >
> > > Am Montag, dem 10.07.2023 um 22:16 +0200 schrieb Alejandro Colomar via 
> > > Gcc:
> > > > On 7/10/23 22:14, Alejandro Colomar wrote:
> > > > > [CC += Andrew]
> > > > >
> > > > > Hi Xi, Andrew,
> > > > >
> > > > > On 7/10/23 20:41, Xi Ruoyao wrote:
> > > > > > Maybe we should have a weaker version of nonnull which only 
> > > > > > performs the
> > > > > > diagnostic, not the optimization.  But it looks like they hate the 
> > > > > > idea:
> > > > > > https://gcc.gnu.org/PR110617.
> > > > > >
> > > > > This is the one thing that makes me use both Clang and GCC to compile,
> > > > > because while any of them would be enough to build, I want as much
> > > > > static analysis as I can get, and so I want -fanalyzer (so I need 
> > > > > GCC),
> > > > > but I also use _Nullable (so I need Clang).
> > > > >
> > > > > If GCC had support for _Nullable, I would have in GCC the superset of
> > > > > features that I need from both in a single vendor.  Moreover, Clang's
> > > > > static analyzer is brain-damaged (sorry, but it doesn't have a simple
> > > > > command line to run it, contrary to GCC's easy -fanalyzer), so having
> > > > > GCC's analyzer get over those _Nullable qualifiers would be great.
> > > > >
> > > > > Clang's _Nullable (and _Nonnull) are not very useful outside of 
> > > > > analyzer
> > > > > mode, as there are many cases where the compiler doesn't have enough
> > > > > information, and the analyzer can get rid of false negatives and
> > > > > positives.  See: 
> > > > >
> > > > > I'll back the ask for the qualifiers 

Re: On pull request workflows for the GNU toolchain

[enh via Gcc]

it doesn't make the patch _management_ problem better ("now i have two
problems"), but https://github.com/landley/toybox takes the "why not both?"
approach --- you can use pull requests if you grew up with/adapted to
git/github, or you can use the mailing list otherwise ... taking into
account that what the "barriers" are depend on whose eye's you're looking
through.

somewhat related, Android's NDK uses github as their issue tracker [while
still having Google's usual "buganizer" issue tracker available] and we get
orders of magnitude more interaction with our users on github --- like it
or not, it's where the users are. anecdotally i notice people report
bugs/send patches to github _mirrors_ of AOSP projects, and have no idea
that's not the actual upstream.


On Mon, Sep 23, 2024 at 9:23 AM Jonathan Wakely 
wrote:

> On Mon, 23 Sept 2024 at 13:09, Thomas Koenig via Gcc 
> wrote:
> >
> > [For the fortran people: Discussion on gcc@]
> >
> > Just a general remark.
> >
> > There are people, such as myself, who regularly mess up
> > their git repositories because they have no mental model
> > of what git is doing
>
> I highly recommend https://www.youtube.com/watch?v=1ffBJ4sVUb4 which
> gives an excellent mental model for the basics (and everything else
> follows from those basic rules).
>
> > (case in point: The Fortran unsigned
> > branch, which I managed to put into an unrepairable state
> > despite considerable help from people who tried to help me
> > fix it). This is especially true of volunteer maintainers,
> > who are still the mainstay of gfortran.
> >
> > Whatever you end up doing, consider such maintainers, and
> > if they still can contribute or would simply give up.
> > If what you end up doing is too complicated, it may end up
> > severely impacting the gfortran project (and possibly others).
>
> We already use Git in all the toolchain projects and there's no
> suggestion to change that.
>
> The discussion is about how we do patch submission and patch review.
> The GitHub pull request workflow is widely seen as simpler than our
> current email-based workflow (not everybody agrees, of course). The
> idea is to *lower* the barrier of entry for contributors, not raise
> it.
>