Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gabriela.gibson@gmail.com
 designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <003201d04eb7$e4f49400$aeddbc00$@acm.org>
References: 
 <CALfVaARs0Y_fB=p_B97wNPRy8v1QvbMahMQF6voYJAUdej_n8g@mail.gmail.com>
 <CALfVaASwMWf=2qJDW-7SJLq+qqFL+RqGyJEspDZ7M4cqjBphBg@mail.gmail.com>
 <811A01B4-256D-4BF1-BCC7-55E3294DACAB@apache.org>
 <CAK2iWdTAWmF84yQip445313of_5GX2z_KZ6bKLfsX=teo=2RyQ@mail.gmail.com>
 <003201d04eb7$e4f49400$aeddbc00$@acm.org>
From: Gabriela Gibson <gabriela.gibson@gmail.com>
Date: Mon, 23 Feb 2015 11:19:47 +0000
Message-ID: 
 <CALfVaAR-AR-ZoJ-hby9VKzL9aMsv+Z-+cGKZm56RhdROdS4pTQ@mail.gmail.com>
Subject: Re: Checking malloc success and adding perror()
To: dev@corinthia.incubator.apache.org, dennis.hamilton@acm.org
Content-Type: multipart/alternative; boundary=001a113ec7b6a28b6d050fbf9528

--001a113ec7b6a28b6d050fbf9528
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thank you very much for that Dennis, this does make life very easy!

G

On Sun, Feb 22, 2015 at 3:54 PM, Dennis E. Hamilton <dennis.hamilton@acm.or=
g
> wrote:

> @Gabriela,
>
> Another way to submit the patches is to open an Issue on this and then
> upload the patch as an attachment to a comment when it is ready.  Zip
> should also work fine.
>
> The Corinthia JIRA is at <https://issues.apache.org/jira/browse/COR/>.
> You will need to create a login for yourself.  That will work for all
> Apache projects that use JIRA, so you only need to do that once.  The
> landing page, above, is a Summary dashboard for the Corinthia subtree
> ("key").  Noodle around on the sidebar to browse issues themselves.  Also=
,
> look at the "More" pull-down on the menu bar at the top of issue pages.
>
> E.g., on the COR Summary page, click Issues.  On the Issues page view All
> issues or all Unresolved using links at the top.  I think if you create t=
he
> issue, you can assign it to yourself and, if not, one of us should be abl=
e
> to assign it to you.
>
> You could report the bug (i.e., unchecked allocations) or you could creat=
e
> a task (or both) and there are probably subtasks that are worth creating =
to
> your overall effort.  You can create sub-tasks on any issue.  Again, if y=
ou
> don't have sufficient karma, ask one of us to do it.
>
> You can experiment with JIRA a little if not familiar with the Apache
> setup of it.  There's little that can't be adjusted if you decide on a
> different structure for organization of issue bits after working a little
> while.
>
> Have fun!  (I once worked for a company VP whose idea of fun was shipping
> code.  I think that applies here for open-source big time.)
>
>  - Dennis
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Sunday, February 22, 2015 04:47
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Checking malloc success and adding perror()
>
> On Sunday, February 22, 2015, Peter Kelly <pmkelly@apache.org> wrote:
>
> > Sounds great - I would just suggest putting the x* function
> > implementations in Wrapper.c rather than having a separate copy in the
> > files for each supported platform. Wrapper.c is sort of our generic pla=
ce
> > to put things which work the same way on all platforms but still need t=
o
> > live in the platform module (as is the case for the zip functions which
> are
> > currently there).
>
> +1 to use wrapper.c
>
> rgds
> jan i
>
> >
> > The memory allocation functions are identical for all platforms so I
> think
> > it would be better to avoid the code duplication - especially since we=
=E2=80=99ll
> > likely modify these for error handling/cleanup etc. and only want to do
> so
> > in one place.
> >
> > If the diffs are really big, you could perhaps post them as zip files t=
o
> > cut down on the size. Either that or post them somewhere we can get the=
m;
> > whatever is most convenient for you.
> >
> > =E2=80=94
> > Dr Peter M. Kelly
> > pmkelly@apache.org <javascript:;>
> >
> > PGP key: http://www.kellypmk.net/pgp-key <
> http://www.kellypmk.net/pgp-key>
> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> >
> > > On 22 Feb 2015, at 7:13 pm, Gabriela Gibson <gabriela.gibson@gmail.co=
m
> > <javascript:;>> wrote:
> > >
> > > Hi,
> > >
> > > I propose to do the following:
> > >
> > > 1) Replace all the calls to *allocs (malloc, calloc, realloc)
> > > {and also free()} with matching x* functions in DocFormats.
> > >
> > > 2) These new x*alloc functions will live in their respective
> > > platform/src files, and will contain a call to the original
> > > *alloc function and a simple exit handler.
> > >
> > > 3) I will create test cases in platform/tests/ for each of those
> > > functions.  I can either put them in WrapperTests.c or create a
> > > new, MallocTests.c file for them.
> > >
> > > 4) I will start out with free(), just to be certain I get the shape
> right
> > > before I process the rest of the to-do list.
> > >
> > > 5) I will ship this as a 'git diff' files.
> > >
> > > What do you think?
> > >
> > > G
> > >
> > > On Wed, Feb 18, 2015 at 9:19 PM, Gabriela Gibson <
> > gabriela.gibson@gmail.com <javascript:;>>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Reading through the source, I see that a lot of mallocs() do not hav=
e
> a
> > >>
> > >> [[
> > >> if(foo =3D=3D NULL) {
> > >>    perror("Foo: Out of memory.\n");
> > >>    return _exit(EXIT_FAILURE);
> > >> }
> > >> ]]
> > >>
> > >> check.
> > >>
> > >> I can add those if you like.
> > >>
> > >> G
> > >> --
> > >> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
> > >>
> > >
> > >
> > >
> > > --
> > > Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
> >
> >
>
> --
> Sent from My iPad, sorry for any misspellings.
>
>


--=20
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

--001a113ec7b6a28b6d050fbf9528--