For Programmers: Free Programming Magazines  


Home > Archive > PHP Pear > September 2007 > Re: [PEAR] CodeGen_PECL int pass-by-reference









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: [PEAR] CodeGen_PECL int pass-by-reference
Justin Patrin

2007-09-12, 10:02 pm

On 9/7/07, Matt Williamson <Matt.Williamson@noaa.gov> wrote:
> Hello list,
>
> Question about CodeGen_PECL:
>
> I'm trying to use this to write a wrapper extension for the netCDF C
> libraries
> ( http://www.unidata.ucar.edu/softwar.../index.html#Top ). but they have a nasty habit of returning values as pass-by-reference. So far I'm not finding a good example of or documentation for how to do this. My attempts so far don't wo

rk, and usually show a message like the following when compiling:
>
> warning: passing argument 3 of 'nc_open' from incompatible pointer type
>
> I'm not a C guru, which could be part of the problem, but still...
>
> Could somebody give me an example of what the <function> tag should look
> like for, say the nc_open function? I think I can figure the rest out on
> my own after that. The C prototype is:
>
> int nc_open (const char *path, int omode, int *ncidp);
>
> Its the last parameter I'm having trouble with, primarily. I need to be
> able to get its value back, so I can pass it to other functions.
>


Are you trying to get back an int or a pointer to an int? In C passing
an int by reference means passing a pointer to an int (int * var). If
the function is allocating an int and returning the pointer to it for
you to use then it would be an int ** var.

--
Justin Patrin
Matthew Williamson

2007-09-13, 4:02 am

On Sep 12, 2007, at 7:15 PM, Justin Patrin wrote:
>
> Are you trying to get back an int or a pointer to an int? In C passing
> an int by reference means passing a pointer to an int (int * var). If
> the function is allocating an int and returning the pointer to it for
> you to use then it would be an int ** var.


No, pretty sure what I need back is a value--I'm not sure what I'd do
with the pointer if it got returned to PHP anyway.

nc_open, for example, takes three parameters. The last parameter is
an int, which the nc_open function modifies, and sets to be what is
basically a filehandle number, which is the handle that is used to
refer to the file in later function calls. The function's /return
value/ is an error code (or zero for no error), so it uses that third
parameter to pass back the filehandle number.

I did figure out part of my problem: the compiler warnings were there
because when CodeGen_PECL generates the C code for the extension, any
"int" types from the prototype are actually represented as "long"s,
so I just had to do some type coercion in the <code> block to get the
warning to go away. But I still have the fundamental problem that the
variable I pass in the third parameter to nc_open doesn't get
modified. E.g.:

<?php
$intHandle = 42;
nc_open('/path/to/file.nc', NC_NOWRITE, $intHandle); // or &
$intHandle ... neither works
echo $intHandle;
?>

outputs "42". I put a printf statement in the <code> block to output
the value that the C code sees (after the wrapped C call to nc_open),
and it was "3", for example. But the changed variable doesn't get
sent back in the third parameter.

Help?!?
Bertrand Mansion

2007-09-13, 4:02 am


Le 13 sept. 07 =E0 05:12, Matthew Williamson a =E9crit :

> On Sep 12, 2007, at 7:15 PM, Justin Patrin wrote:
>
> No, pretty sure what I need back is a value--I'm not sure what I'd =20
> do with the pointer if it got returned to PHP anyway.
>
> nc_open, for example, takes three parameters. The last parameter is =20=


> an int, which the nc_open function modifies, and sets to be what is =20=


> basically a filehandle number, which is the handle that is used to =20
> refer to the file in later function calls. The function's /return =20
> value/ is an error code (or zero for no error), so it uses that =20
> third parameter to pass back the filehandle number.
>
> I did figure out part of my problem: the compiler warnings were =20
> there because when CodeGen_PECL generates the C code for the =20
> extension, any "int" types from the prototype are actually =20
> represented as "long"s, so I just had to do some type coercion in =20
> the <code> block to get the warning to go away. But I still have =20
> the fundamental problem that the variable I pass in the third =20
> parameter to nc_open doesn't get modified. E.g.:
>
> <?php
> $intHandle =3D 42;
> nc_open('/path/to/file.nc', NC_NOWRITE, $intHandle); // or &=20
> $intHandle ... neither works
> echo $intHandle;
> ?>
>
> outputs "42". I put a printf statement in the <code> block to =20
> output the value that the C code sees (after the wrapped C call to =20
> nc_open), and it was "3", for example. But the changed variable =20
> doesn't get sent back in the third parameter.


You should ask your questions on the PECL list since they are not =20
related to CodeGen_PECL.
For such functions, I'd recommend writing a wrapper function, which =20
means you'd have to change the API a bit. In this case, I think the =20
function should return a resource, not an int. In fact, the nc_open() =20=

C function should be used inside another function and which in turn =20
would return a resource. IIRC, that's how the sqlite wrapper for PDO =20
does, for example. I think pretty much every PHP extension does so. =20
You might want to have a look at other extensions and how they open =20
files and return a PHP resource.



--
Bertrand Mansion
Mamasam
Work : http://www.mamasam.com
Blog : http://golgote.freeflux.net
Matthew Williamson

2007-09-13, 7:03 pm

On Sep 13, 2007, at 1:51 AM, Bertrand Mansion wrote:
> You should ask your questions on the PECL list since they are not
> related to CodeGen_PECL.
> For such functions, I'd recommend writing a wrapper function, which
> means you'd have to change the API a bit. In this case, I think the
> function should return a resource, not an int. In fact, the nc_open
> () C function should be used inside another function and which in
> turn would return a resource. IIRC, that's how the sqlite wrapper
> for PDO does, for example. I think pretty much every PHP extension
> does so. You might want to have a look at other extensions and how
> they open files and return a PHP resource.


Well, no, actually my question does have to do with CodeGen_PECL,
because I want to know what the <function> tag and contents will look
like to do this.

I'd considered making the PHP function behave differently than the C
function, it does seem it would be more PHP-like, but there are a
number of obvious advantages to mimicking the function exactly.
Namely, we've already got developers that are familiar with the C
API, so it reduces the learning curve, also I wouldn't have to re-
write any documentation if it behaves exactly like the C functions,
which SHOULD be possible.

So, to ask again, I want to know what the <function> tag,
specifically the <proto> and <code> tags would look like if you
wanted to do pass-by-reference (and get a modified value back) in one
of the parameters. That's the question. Perhaps I've overcomplicated
it with a real-world example, but that is what I want to know.

Thanks.
Bertrand Mansion

2007-09-13, 7:03 pm


Le 13 sept. 07 =E0 14:56, Matthew Williamson a =E9crit :

> So, to ask again, I want to know what the <function> tag, =20
> specifically the <proto> and <code> tags would look like if you =20
> wanted to do pass-by-reference (and get a modified value back) in =20
> one of the parameters. That's the question. Perhaps I've =20
> overcomplicated it with a real-world example, but that is what I =20
> want to know.


You should ask on the PECL list, I think Harmut, the CodeGen_PECL =20
author, hangs around there more often.



--
Bertrand Mansion
Mamasam
Work : http://www.mamasam.com
Blog : http://golgote.freeflux.net
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com