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 the access direction to catch many bugs.
>
> You might be right. But I think the annotations could help to catch
> use-after-close errors.
>
> By the way, I think it would help us if we didn't have to special-
> case
> AT_FDCWD using inline wrappers.
Florian: I confess I wasn't familiar with AT_FDCWD until I read your
email and did a little reading a few minutes ago; it seems to be a
"magic number" for an FD that has special meaning; on my system it has
the value -100.
GCC's current implementation of the various -Wanalyzer-fd-* warnings
will track state for constant integer values as well as symbolic
values; it doesn't have any special meanings for specific integer
values. So e.g. it doesn't assume that 0, 1, and 2 have specific
meaning or are opened with specific flags (the analysis doesn't
necessarily begin its execution path at the start of "main", so there's
no guarantee that the standard FDs have their standard meaning).
Presumably if someone attempts
close (AT_FDCWD);
they'll get -1 and errno set to EBADFD, right? I don't think GCC's -
fanalyzer needs to check for that.
-fanalyzer's filedescriptor support doesn't yet have a concept of
"directory filedescriptors". Should it? (similarly, it doesn't yet
know about sockets)
A possible way to annotate "openat":
int openat(int dirfd, const char *pathname, int flags)
__attr_fd_arg(1);
Dave
>
> Thanks,
> Florian
>
