GSoC proposal for extending static analyzer

GSoC proposal for extending static analyzer

[Mir Immad]

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.

Re: GSoC proposal for extending static analyzer

[David Malcolm]

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

Re: GSoC proposal for extending static analyzer

[Mir Immad]

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?
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.


> 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.



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
>
>
>

Re: GSoC proposal for extending static analyzer

[David Malcolm]

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
> > 
> > 
> >