On 7/14/22 08:22, David Malcolm via Libc-alpha wrote:
The analyzer now attempts to track both file descriptors and stdio
streams, so we probably need to special-case fdopen
You probably also need to special-case fileno, which goes the opposite
direction.
If you're handling DIR *, fdopendir a
On Thu, 2022-07-14 at 09:30 +0100, Szabolcs Nagy wrote:
> The 07/13/2022 12:55, David Malcolm wrote:
> > On Wed, 2022-07-13 at 16:01 +0200, Florian Weimer wrote:
> > > * David Malcolm:
> > GCC trunk's -fanalyzer implements the new warnings via a state
> > machine
> > for file-descriptor values; it
The 07/13/2022 12:55, David Malcolm wrote:
> On Wed, 2022-07-13 at 16:01 +0200, Florian Weimer wrote:
> > * David Malcolm:
> GCC trunk's -fanalyzer implements the new warnings via a state machine
> for file-descriptor values; it currently has rules for handling "open",
> "close", "read", and "write
On Wed, 2022-07-13 at 22:26 +0530, Mir Immad wrote:
> Hi everyone,
>
> Reading through the thread, I feel the following attributes look good
> and
> similar to what I've done:
>
> __attribute__ ((fd_arg(N)))
> __attribute__ ((fd_arg_read(N)))
> __attribute__ ((fd_arg_write(N)))
>
> I believe how
Hi everyone,
Reading through the thread, I feel the following attributes look good and
similar to what I've done:
__attribute__ ((fd_arg(N)))
__attribute__ ((fd_arg_read(N)))
__attribute__ ((fd_arg_write(N)))
I believe how to annotate the glibc headers is a separate discussion.
Dave: From the
On Wed, 2022-07-13 at 16:01 +0200, Florian Weimer wrote:
> * David Malcolm:
>
> > On Wed, 2022-07-13 at 14:05 +0200, Florian Weimer wrote:
> > > * Szabolcs Nagy via Gcc:
> >
> > [adding Immad back to the CC list]
> >
> > >
> > > > to be honest, i'd expect interesting fd bugs to be
> > > > dynam
* David Malcolm:
> On Wed, 2022-07-13 at 14:05 +0200, Florian Weimer wrote:
>> * Szabolcs Nagy via Gcc:
>
> [adding Immad back to the CC list]
>
>>
>> > to be honest, i'd expect interesting fd bugs to be
>> > dynamic and not easy to statically analyze.
>> > the use-after-unchecked-open maybe usef
On Wed, 2022-07-13 at 14:05 +0200, Florian Weimer wrote:
> * Szabolcs Nagy via Gcc:
[adding Immad back to the CC list]
>
> > to be honest, i'd expect interesting fd bugs to be
> > dynamic and not easy to statically analyze.
> > the use-after-unchecked-open maybe useful. i would
> > not expect th
On Wed, 2022-07-13 at 09:37 +0100, Szabolcs Nagy wrote:
> The 07/12/2022 18:25, David Malcolm via Libc-alpha wrote:
> > On Tue, 2022-07-12 at 18:16 -0400, David Malcolm wrote:
> > > On Tue, 2022-07-12 at 23:03 +0530, Mir Immad wrote:
> > > GCC's attribute syntax here:
> > > https://gcc.gnu.org/on
* Szabolcs Nagy via Gcc:
> to be honest, i'd expect interesting fd bugs to be
> dynamic and not easy to statically analyze.
> the use-after-unchecked-open maybe useful. i would
> not expect the access direction to catch many bugs.
You might be right. But I think the annotations could help to cat
On Jul 13 2022, Szabolcs Nagy via Libc-alpha wrote:
> note that glibc headers have to be namespace clean so it
> would be more like
>
> __attribute__((__fd_argument (__access, 1)))
> __attribute__((__fd_argument (__read, 1)))
> __attribute__((__fd_argument (__write, 1)))
>
> so it would be e
The 07/12/2022 18:25, David Malcolm via Libc-alpha wrote:
> On Tue, 2022-07-12 at 18:16 -0400, David Malcolm wrote:
> > On Tue, 2022-07-12 at 23:03 +0530, Mir Immad wrote:
> > GCC's attribute syntax here:
> > https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
> > allows for a parenthesized
On Tue, 2022-07-12 at 18:16 -0400, David Malcolm wrote:
> On Tue, 2022-07-12 at 23:03 +0530, Mir Immad wrote:
>
> [cross-posting to the glibc development mailing list; updating subject
> accordingly]
>
> > Hi everyone,
>
> Hi Immad, GCC developers, and glibc developers.
>
> glibc developers: Im
13 matches
Mail list logo
