From: David Malcolm <dmalcolm@redhat.com>
To: Mir Immad <mirimnan017@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: Re: GSoC proposal for extending static analyzer
Date: Sat, 16 Apr 2022 07:51:25 -0400 [thread overview]
Message-ID: <ed2b92f254ed2c1de3bf2113e0e3983183b4c510.camel@redhat.com> (raw)
In-Reply-To: <CAE1-7oxTUoOBC=j32vjXvOPxKmdxEPn2uFuy6BTTBk6Da3CWWA@mail.gmail.com>
On Fri, 2022-04-15 at 22:36 +0530, Mir Immad wrote:
> I've updated the link on the repo --
> https://mirimmad.github.io/zeta-lang.
>
> > You don't give many specifics in your personal decription. One thing
> > I'm not seeing is a sense of how proficient you are in various
> > programming languages. In particular, how is your C and C++? How
> > familiar are you with the debugger? Looking at your github, you seem
> > to have relevant experience in compilers, which is great, but all
> > your
> > code appears to be with "managed" languages such as Ruby, Java, and
> > Python [and Zeta :)].
>
> I'm pretty comfortable with both C and C++ and manual mem management .
> Unfortunately, I don't have any project in C/C++ to show. Maybe I can
> use
> the time before May 20 to write something in cpp?
Perhaps write some low-level code in C and/or C++ that uses file-
descriptors? That would help you gain familiarity with both C/C++, and
with the problem domain. (in terms of what does good code look like,
and also, what are the ways in which a programmer can make mistakes
when using a particular API).
> About the debugger, I'm okay-ish with it. In fact, it was due to the
> debugger (and your blog on it) that I was initially able to walk
> through
> the codebase.
(nods)
>
>
> > That said, I got
> > the sense from your previous emails that you're not very familiar
> > with
> > the APIs, and that you chose them because that was the suggestion I
> > had
> > made on the wiki page.
>
> thats right.
>
>
> > Obviously it's something you can learn on the
> > way, but it would be better to accurately identify which areas
> > you're
> > going need to learn along the way, and the timetable and scope should
> > reflect that.
>
> If I understand the statement correctly; currently I'm thinking of
> extending the support for open() (for creating the fd), write/read (for
> working on the fd) and close(). This is quite analogous to what we have
> in
> sm-file. Please let me know how do you want the analyzer to be extended
> and
> if you expect support for any other FD APIs too as I understand there
> are
> many other APIs for creating and working wiith FDs?
>
> Thank you.
There are a lot of them; see e.g.:
https://en.wikipedia.org/wiki/File_descriptor
Perhaps it's worth considering implementing some kind of attribute for
function-decls to specify what their behavior is with regards to file
descriptors, rather than hardcoding the expected behaviors
individually? (not sure, perhaps one part of the project will be to
catalog the different expected preconditions and behaviors of API
entrypoints that work with file descriptors, in that I expect that they
will fall into patterns).
BTW, I'm about to go on a week-long trip, and will be away from the
computer during that time, so I probably won't be able to reply further
before the application deadline.
Hope this is helpful
Dave
>
>
>
> On Fri, Apr 15, 2022 at 9:35 PM David Malcolm <dmalcolm@redhat.com>
> wrote:
>
> > On Fri, 2022-04-15 at 19:58 +0530, Mir Immad wrote:
> > > I've submitted a proposal for extending the static analyzer to
> > > support
> > > posix fd APIs on GSoC website. Here is the Google docs link (gdocs
> > > <
> > >
> > https://docs.google.com/document/d/188zxPUsuYcF-uGVYL_G1s2RVtHhJSZeQ4sha40H7374/edit?usp=sharing
> > > > ).
> > >
> > >
> > > Please take a look and let me know what you think.
> > >
> > > Thank you.
> >
> > Thanks.
> >
> > FWIW, I'm getting an error when trying the URL given in your github
> > repo: http://mirimmad.me/
> > but https://mirimmad.github.io/ seems to work - but it's almost
> > empty.
> >
> > You don't give many specifics in your personal decription. One thing
> > I'm not seeing is a sense of how proficient you are in various
> > programming languages. In particular, how is your C and C++? How
> > familiar are you with the debugger? Looking at your github, you seem
> > to have relevant experience in compilers, which is great, but all
> > your
> > code appears to be with "managed" languages such as Ruby, Java, and
> > Python [and Zeta :)].
> >
> > Also, the proposal is to extend the analyzer to cover a specific
> > domain: various POSIX APIs. Can you please give a sense of your
> > level
> > of expertise with these APIs? I was pleased at your initiative in
> > trying to reuse the existing code to work with them. That said, I
> > got
> > the sense from your previous emails that you're not very familiar
> > with
> > the APIs, and that you chose them because that was the suggestion I
> > had
> > made on the wiki page. Obviously it's something you can learn on the
> > way, but it would be better to accurately identify which areas you're
> > going need to learn along the way, and the timetable and scope should
> > reflect that.
> >
> > Hope this is constructive
> > Dave
> >
> >
> >
prev parent reply other threads:[~2022-04-16 11:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-15 14:28 Mir Immad
2022-04-15 16:05 ` David Malcolm
2022-04-15 17:06 ` Mir Immad
2022-04-16 11:51 ` David Malcolm [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ed2b92f254ed2c1de3bf2113e0e3983183b4c510.camel@redhat.com \
--to=dmalcolm@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=mirimnan017@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).