Re: Patch for Inline::C-Cookbook

[Neil Watkiss]

Hi Ken,

You shouldn't mix this:

soldier-name = strdup(name);

with this:

Safefree(soldier-name);

because strdup() is just a C library function that uses malloc(), and
Safefree might not be. You want to use savepv(), which is the Perl API's
equivalent that's guaranteed to work with Safefree.

Have a look at 'perldoc perlapi' for more info.

Later,
Neil

Re: Patch for Inline::C-Cookbook

[Ken Williams]

On Monday, September 2, 2002, at 06:41 PM, Neil Watkiss wrote:

 Hi Ken,

 You shouldn't mix this:

soldier-name = strdup(name);

 with this:

Safefree(soldier-name);

 because strdup() is just a C library function that uses malloc(), and
 Safefree might not be. You want to use savepv(), which is the 
 Perl API's
 equivalent that's guaranteed to work with Safefree.

 Have a look at 'perldoc perlapi' for more info.



Wow, I'd never have known that from `perldoc perlapi`.  I had to 
look at `perldoc perlclib`, which I'd never even *heard* of 
before, and which I'd never have found without `grep savepv 
/usr/share/man/man1/perl*`.

I'll be changing this in my own code now too.  Thanks for the pointer.

  -Ken

Re: Patch for Inline::C-Cookbook

[Piers Harding]

Perl is full of surprises :-) - I'd never heard of it too, or perlapio (
pointed to herein ) *sigh* so little time so much to learn 

Cheers.


On Tue, Sep 03, 2002 at 12:09:05PM +1000, Ken Williams wrote:
 
 On Monday, September 2, 2002, at 06:41 PM, Neil Watkiss wrote:
 
  Hi Ken,
 
  You shouldn't mix this:
 
 soldier-name = strdup(name);
 
  with this:
 
 Safefree(soldier-name);
 
  because strdup() is just a C library function that uses malloc(), and
  Safefree might not be. You want to use savepv(), which is the 
  Perl API's
  equivalent that's guaranteed to work with Safefree.
 
  Have a look at 'perldoc perlapi' for more info.
 
 
 
 Wow, I'd never have known that from `perldoc perlapi`.  I had to 
 look at `perldoc perlclib`, which I'd never even *heard* of 
 before, and which I'd never have found without `grep savepv 
 /usr/share/man/man1/perl*`.
 
 I'll be changing this in my own code now too.  Thanks for the pointer.
 
   -Ken

Re: Patch for Inline::C-Cookbook

[Sisyphus]

- Original Message -
From: Ken Williams [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, September 01, 2002 12:49 AM
Subject: Patch for Inline::C-Cookbook


 Hi,

 The C-Cookbook has the following code for doing object-oriented Inline:

  SV* new(char* class, char* name, char* rank, long serial) {
  Soldier* soldier = malloc(sizeof(Soldier));
  SV*  obj_ref = newSViv(0);
  SV*  obj = newSVrv(obj_ref, class);

  soldier-name = strdup(name);
  soldier-rank = strdup(rank);
  soldier-serial = serial;

  sv_setiv(obj, (IV)soldier);
  SvREADONLY_on(obj);
  return obj_ref;
  }

 I've found that the following simpler code works just as well:

  SV* new(char* class, char* name, char* rank, long serial) {
Soldier* soldier = malloc(sizeof(Soldier));

soldier-name = strdup(name);
soldier-rank = strdup(rank);
soldier-serial = serial;

return sv_setref_pv(newSViv(0), class, (void *)soldier);
  }

 Any reason not to use that?


Only time I used 'malloc()' and 'free()' in an inline function I struck
problems if the function was called a number of times. I forget just how big
that 'number of times' was - and the amount of memory involved might well
have had a bearing. (It worked fine if the function was called only once -
which led me to believe that 'free()' was not doing the job, and the memory
was being freed only when the app terminated.)

Someone posted the recommendation that 'New()' and 'Safefree()' be used
instead, and I've been using them with no trouble.

Doing a benchmark on a thousand or so iterations might bring any problem to
light.
Or was my problem just a M$ issue  or are there some other 'ifs and
buts' involved that render this post inapplicable ?

Anyway ... just thought I'd mention it :-)

Cheers,
Rob

Re: Patch for Inline::C-Cookbook

[Ken Williams]

On Monday, September 2, 2002, at 11:35 AM, Sisyphus wrote:

 Only time I used 'malloc()' and 'free()' in an inline function I struck
 problems if the function was called a number of times. I forget 
 just how big that 'number of times' was - and the amount of 
 memory involved might well have had a bearing. (It worked fine 
 if the function was called only once - which led me to believe 
 that 'free()' was not doing the job, and the memory was being 
 freed only when the app terminated.)

 Someone posted the recommendation that 'New()' and 'Safefree()' be used
 instead, and I've been using them with no trouble.

You could be right - I wasn't sure whether New() and Safefree() 
would work properly with both -Dusemymalloc and without it.  Is 
it safe in both situations?

  -Ken

Re: Patch for Inline::C-Cookbook

[Iain Truskett]

* Ken Williams ([EMAIL PROTECTED]) [02 Sep 2002 15:48]:
 On Monday, September 2, 2002, at 11:35 AM, Sisyphus wrote:
[...]
  Someone posted the recommendation that 'New()' and 'Safefree()' be
  used instead, and I've been using them with no trouble.

 You could be right - I wasn't sure whether New() and Safefree() would
 work properly with both -Dusemymalloc and without it.  Is it safe in
 both situations?

As I understand it, New() and Safefree() [and Renew()] will do
whatever's appropriate in order to make things as reliable as can be.

malloc, free, realloc could do anything. Depending on system, colour of
moon, etc.

In XS/Inline, use the Perl functions. They'll work out whether they're
using the system malloc, a custom malloc, and treat everything
appropriately carefully. If they fail, then you're screwed.

Of course, that's my interpretation, and I could well be wrong.


cheers,
-- 
Iain.

Re: Patch for Inline::C-Cookbook

[Ken Williams]

On Monday, September 2, 2002, at 11:35 AM, Sisyphus wrote:
 Only time I used 'malloc()' and 'free()' in an inline function 
 I struck problems if the function was called a number of times. 
 I forget just how big that 'number of times' was - and the 
 amount of memory involved might well have had a bearing. (It 
 worked fine if the function was called only once - which led me 
 to believe that 'free()' was not doing the job, and the memory 
 was being freed only when the app terminated.)

 Someone posted the recommendation that 'New()' and 'Safefree()' be used
 instead, and I've been using them with no trouble.

I looked a little closer at the docs, and I think you're right.  
So here's an updated version of the constructor/destructor 
routines:

SV* new(char* class, char* name, char* rank, long serial) {
   Soldier* soldier;
   New(0, soldier, 1, Soldier);

   soldier-name = strdup(name);
   soldier-rank = strdup(rank);
   soldier-serial = serial;

   return sv_setref_pv(newSViv(0), class, (void *)soldier);
}

void DESTROY(SV* obj) {
   Soldier* soldier = (Soldier*)SvIV(SvRV(obj));
   Safefree(soldier-name);
   Safefree(soldier-rank);
   Safefree(soldier);
}


It would also be nice to show a typemap that gets rid of all the 
typecasting, object wrapping, etc. here and just lets you use a 
Soldier* type in prototypes.

  -Ken

Patch for Inline::C-Cookbook

[Ken Williams]

Hi,

The C-Cookbook has the following code for doing object-oriented Inline:

 SV* new(char* class, char* name, char* rank, long serial) {
 Soldier* soldier = malloc(sizeof(Soldier));
 SV*  obj_ref = newSViv(0);
 SV*  obj = newSVrv(obj_ref, class);

 soldier-name = strdup(name);
 soldier-rank = strdup(rank);
 soldier-serial = serial;

 sv_setiv(obj, (IV)soldier);
 SvREADONLY_on(obj);
 return obj_ref;
 }

I've found that the following simpler code works just as well:

 SV* new(char* class, char* name, char* rank, long serial) {
   Soldier* soldier = malloc(sizeof(Soldier));

   soldier-name = strdup(name);
   soldier-rank = strdup(rank);
   soldier-serial = serial;

   return sv_setref_pv(newSViv(0), class, (void *)soldier);
 }

Any reason not to use that?

  -Ken