[ swig-Patches-3522674 ] Java STRING_OUT typemap could use uninitialized memory

Patches item #3522674, was opened at 2012-04-30 18:40
Message generated for change (Tracker Item Submitted) made by ldav1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=3522674&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Leo Davis (ldav1s)
Assigned to: Nobody/Anonymous (nobody)
Summary: Java STRING_OUT typemap could use uninitialized memory

Initial Comment:
I noticed that the STRING_OUT typemap could possibly reference uninitialized memory:

  char **arg1 = (char **) 0 ;
  char *temp1 ; // here's the uninitialized memory
...
    arg1 = &temp1;  // we point at the uninitialized memory
 }
  result = (int)foo(arg1); // foo() takes a code path that does not set up *arg1, like returning immediately
  jresult = (jint)result; 
  {
    jstring jnewstring = NULL;

Re: GSoC: Creating svn branches for students?

On 28/04/12 13:14, Vadim Zeitlin wrote:
>   Hi,
>
>   Should we create svn branches for the students already? Unless we 
> plan to
> switch to git some time soon (wink wink nudge nudge , I think we should
> do it a.s.a.p. to let people start working even before the official GSoC
> beginning if they feel like it, any objections? If not, should I just
> create the branch for the student whom I'm mentoring or will William 
> create
> all branches at once? And, if I do need to create it myself, should we
> branch from rel-2.0.5 or the current trunk?
>
>   I'd also like to use slightly different branches names if possible: the
> current convention is to use gsoc$YEAR-$STUDENT (see
> http://swig.svn.sourceforge.net/viewvc/swig/branches/) but this is not
> terribly clear for someone not intimately familiar with the project so 
> what
> about using gsoc$YEAR-$PROJECT-$STUDENT or, perhaps, just 
> gsoc$YEAR-$PROJECT
> as presumably the students know which project they're working on anyhow?
> E.g. something like gsoc2012-c-backend[-leif.middelschulte] for the Leif's
> project that I'd be mentoring?
Yes, I can set up branches now. Can all the GSoC students please send me 
their SourceForge usernames, as the branches are named after SF 
usernames. Vadim's idea of adding in the project name to give more 
context to the branch name is a good idea too.

It seems that git is the way forward, so I suspect we will end up 
switching sometime this year. But while I haven't had the time to get up 

Re: GSoC: Creating svn branches for students?

I had in mind that all students have their own branch so that their 
works can be easily identified and if it is necessary kept separate from 
any other work that has been done and that might progress the branch 
independently. If you want to work more collaboratively on this branch, 
then we can do so. A branch is just a name after all and the same 
information can be obtained from one branch, it is just a convention 
having a new branch name.

William

On 30/04/12 10:21, Vincent COUVERT wrote:
> Hi all,
>
> About the Scilab-6 project, we do not need any new branch because we
> already have one (gsoc2009-sploving) which has never been merged into
> the trunk and contains the whole Scilab-Swig wrapping code.
>
> Regards,
> Vincent
>
> Le 28/04/12 14:14, Vadim Zeitlin a écrit :
>>   Hi,
>>
>>   Should we create svn branches for the students already? Unless we plan to
>> switch to git some time soon (wink wink nudge nudge , I think we should
>> do it a.s.a.p. to let people start working even before the official GSoC
>> beginning if they feel like it, any objections? If not, should I just
>> create the branch for the student whom I'm mentoring or will William create
>> all branches at once? And, if I do need to create it myself, should we
>> branch from rel-2.0.5 or the current trunk?

Re: Embedded Lua patch

I'd rather see a fix that doesn't duplicate these macros.

William

On 01/05/12 14:54, Raman Gopalan wrote:
>
> Hello William,
>
> %insert("runtime") %{
> /* Lua flavors */
> #define SWIG_LUA_FLAVOR_LUA 1
> #define SWIG_LUA_FLAVOR_ELUA 2
> #define SWIG_LUA_FLAVOR_ELUAC 3
>
> By defining the above macros (from lua.swg) in luarun.swg I
> was able to fix the issue. Please look for the patch. Please
> let me know if this works.
>
> Best,
> Raman
>
> On Mon, Apr 30, 2012 at 8:02 PM, William S Fulton
> <wsf <at> fultondesigns.co.uk <mailto:wsf <at> fultondesigns.co.uk>> wrote:
>
>     Hi Raman
>
>     Could you please take another look at your embedded Lua patch - I
>     just noticed it breaks certain usage when using an external runtime.
>     See below:
>

[ swig-Patches-3522855 ] Java OUTPUT typemap could use uninitialized memory

Patches item #3522855, was opened at 2012-05-01 13:38
Message generated for change (Tracker Item Submitted) made by ldav1s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=3522855&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Leo Davis (ldav1s)
Assigned to: Nobody/Anonymous (nobody)
Summary: Java OUTPUT typemap could use uninitialized memory

Initial Comment:
In SWIG 2.0.6, I noticed that the OUTPUT typemap generates JNI code where uninitialized memory could be used.

  int *arg1 = (int *) 0 ;
  int temp1 ; // the uninitialized memory
...

    arg1 = &temp1; // uninitialized memory is referenced
 }
  result = (int)foo(arg1); // call into user code which does not write into arg1 (temp1) for some reason
  jresult = (jint)result; 
  {

Re: GSoC: Creating svn branches for students?

Hi William,

Since the gsoc2009-sploving is not stable yet and some functionalities 
are missing in it, I think that Wolfgang will first have to complete the 
on-going work in this development branch so I would prefer to keep this 
single branch for Scilab even if it is not the standard way to go.

Vincent

Le 01/05/12 21:26, William S Fulton a écrit :
> I had in mind that all students have their own branch so that their 
> works can be easily identified and if it is necessary kept separate 
> from any other work that has been done and that might progress the 
> branch independently. If you want to work more collaboratively on this 
> branch, then we can do so. A branch is just a name after all and the 
> same information can be obtained from one branch, it is just a 
> convention having a new branch name.
>
> William
>
>
> On 30/04/12 10:21, Vincent COUVERT wrote:
>> Hi all,
>>
>> About the Scilab-6 project, we do not need any new branch because we
>> already have one (gsoc2009-sploving) which has never been merged into
>> the trunk and contains the whole Scilab-Swig wrapping code.
>>
>> Regards,
>> Vincent

Re: GSoC: Creating svn branches for students?

On Wed, 02 May 2012 10:24:38 +0200 Vincent COUVERT <vincent.couvert <at> scilab.org> wrote:

VC> Since the gsoc2009-sploving is not stable yet and some functionalities 
VC> are missing in it, I think that Wolfgang will first have to complete the 
VC> on-going work in this development branch so I would prefer to keep this 
VC> single branch for Scilab even if it is not the standard way to go.

 Hello,

 GSoC rules require that the student work be easily visible/available and
the simplest way to ensure that it is is to do all of it on a branch. It
doesn't matter if you start this branch from the trunk or from another
existing branch but you really should have it.

 What exactly is the problem with branching gsoc2012-whatever from the
current tip of gsoc2009-sploving? It would, of course, be preferable to
merge with the trunk first so that the branches don't diverge too far but
if you don't want/can't do this, you can still create a new branch from
this one, I really don't see how could it possibly inconvenience anybody?

 Regards,
VZ

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: GSoC: Creating svn branches for students?

The problem is that I have to merge too branches to get the trunk 
modifications into the gsoc2012-branch but I agree it is not so 
difficult and it is better to make the student modifications visible.

Ok for me to create a new branch from gsoc2009-sploving and following 
the standard way.

Regards,
Vincent

Le 02/05/12 11:38, Vadim Zeitlin a écrit :
> On Wed, 02 May 2012 10:24:38 +0200 Vincent COUVERT<vincent.couvert <at> scilab.org>  wrote:
>
> VC>  Since the gsoc2009-sploving is not stable yet and some functionalities
> VC>  are missing in it, I think that Wolfgang will first have to complete the
> VC>  on-going work in this development branch so I would prefer to keep this
> VC>  single branch for Scilab even if it is not the standard way to go.
>
>   Hello,
>
>   GSoC rules require that the student work be easily visible/available and
> the simplest way to ensure that it is is to do all of it on a branch. It
> doesn't matter if you start this branch from the trunk or from another
> existing branch but you really should have it.
>
>   What exactly is the problem with branching gsoc2012-whatever from the
> current tip of gsoc2009-sploving? It would, of course, be preferable to
> merge with the trunk first so that the branches don't diverge too far but
> if you don't want/can't do this, you can still create a new branch from
> this one, I really don't see how could it possibly inconvenience anybody?

SF username

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

SourceForge username

Hi,
>
>   Should we create svn branches for the students already? Unless we
> plan to
> switch to git some time soon (wink wink nudge nudge , I think we should
> do it a.s.a.p. to let people start working even before the official GSoC
> beginning if they feel like it, any objections? If not, should I just
> create the branch for the student whom I'm mentoring or will William
> create
> all branches at once? And, if I do need to create it myself, should we
> branch from rel-2.0.5 or the current trunk?
>
>   I'd also like to use slightly different branches names if possible: the
> current convention is to use gsoc$YEAR-$STUDENT (see
> http://swig.svn.sourceforge.net/viewvc/swig/branches/) but this is not
> terribly clear for someone not intimately familiar with the project so
> what
> about using gsoc$YEAR-$PROJECT-$STUDENT or, perhaps, just
> gsoc$YEAR-$PROJECT
> as presumably the students know which project they're working on anyhow?
> E.g. something like gsoc2012-c-backend[-leif.middelschulte] for the Leif's
> project that I'd be mentoring?
Yes, I can set up branches now. Can all the GSoC students please send me
their SourceForge usernames, as the branches are named after SF
usernames. Vadim's idea of adding in the project name to give more
context to the branch name is a good idea too.

My SourceForge username is: neha1

Regards,
Neha

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/