public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Feng <ef2648@columbia.edu>
To: Steven Sun <StevenSun2021@hotmail.com>
Cc: David Malcolm <dmalcolm@redhat.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Query status of GSoC project: CPyChecker
Date: Wed, 28 Jun 2023 18:09:08 -0400	[thread overview]
Message-ID: <CANGHATV+g4ncZo6RXOfrw6Y=+0xu3Vn8Nu03uP4kgPqNa0WAuA@mail.gmail.com> (raw)
In-Reply-To: <TYAP286MB052157EE8D56FEB829ADE1B0B927A@TYAP286MB0521.JPNP286.PROD.OUTLOOK.COM>

Hi Steven,

Thanks for reaching out. The project is still in very early stages. So
far we have taught the analyzer the basic behavior for
PyLong_FromLong, PyList_New, and Py_DECREF via known function
subclassing. Additionally, Py_INCREF is supported out of the box.
Reference count checking functionality remains the priority, but it is
not yet fully implemented.

Regarding CPython versions, the goal is to just get things working on
one version first. I arbitrarily picked 3.9, but happy to consider
another version as an initial goal if it’s more helpful to the CPython
community.

Feel free to check out the repo at
https://github.com/efric/gcc-cpython-analyzer for details on the
project and to follow along and help out where you are interested.

Best,
Eric


On Tue, Jun 27, 2023 at 6:03 AM Steven Sun <StevenSun2021@hotmail.com> wrote:
>
> Hi Eric, I am Steven (now) from the CPython team.
>
> How is the project going? Do you have any prototypes
> or ideas that can be discussed? Which part will you start at?
>
>
> I recently debugged dozens of Python bugs, some involving
> C APIs. I can provide some test cases for you.
>
>
> For the ref count part:
>
> A major change (immortal objects) is introduced in Python 3.12.
> Basically, immortal objects will have the ref count fixed at
> a very large number (depending on `sizeof(void*)` ). But I
> don't think it is necessary to implement this in the early
> stages.
>
> Some stable API steals reference conditionally (on success),
> thus its behavior cannot be simply described by one attribute.
>
>
> For CPython versions:
>
> Some stable CPython API behavior varied across the minor
> release. (eg. 3.10 -> 3.11) For instance, some API accepted
> NULL as args for <3.8, but not >=3.8.
>
> Considering both "GCC" and "CPython" are hard for users to
> upgrade, we might want to consider how to live with these
> behavioral differences in the first place.
>
> Versions older than 3 minor releases cannot be touched. (3.13
> now in active development, 3.12, 3.11 for bug fixes, 3.10, 3.9
> security fixes only) So, versions <= 3.10 can be treated as frozen.

  reply	other threads:[~2023-06-28 22:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 10:03 Steven Sun
2023-06-28 22:09 ` Eric Feng [this message]
2023-06-29  7:40   ` Steven Sun

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='CANGHATV+g4ncZo6RXOfrw6Y=+0xu3Vn8Nu03uP4kgPqNa0WAuA@mail.gmail.com' \
    --to=ef2648@columbia.edu \
    --cc=StevenSun2021@hotmail.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc@gcc.gnu.org \
    /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).