Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > void pointers

Reply
Thread Tools

void pointers

 
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-05-2008
bcpkh <(E-Mail Removed)> writes:

> Below a cut and paste from the supplied header;
>
> void init(GER_t *pStatus,
> void *ociEnvInfo[],
> OMinfo_t *pInfo);
>
> init gets called by the 'parent' process once when it starts and I
> need to use the passed DB info to interact with the database.


This suggests that your prototype for init is wrong. It should look
the above. You were accessing the first parameter, whereas now it
looks like thge seond is the one you want, and rather than being a
void * it points to an array of void pointers. You function must look
like the above if that is what the called expects.

Note also that your previous code should have had errors saying, in
effect, that the definition of init does not match its prototype. If
you did not, then either you did not include this header (and it is
probably a good thing to do that) or you have the warning level set
rather low on your compiler.

--
Ben.
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      08-05-2008
bcpkh wrote:
>
> Hope someone can help me, please note that at first this might
> look as if it is posted to the wrong group but if you ignore the
> specifics I think it is general pointer referencing issue.
>
> I am building a plug-in library and is passed, according to the
> documentation the following;
>
> 'A pointer to the OCI environment handle and server context handle
> are supplied via elements zero and one of ociEnvInfo respectively.
> Implementations are free to ignore this parameter, and should do so
> unless it is intended to use the Oracle connection of the calling
> process.'
>
> void init(void *ociEnvInfo )


You are definitely on the wrong group. We deal with standard C,
and things programmable in standard C. You have omitted the source
of the "OCI environment", without which there is no answer on this
newsgroup. I believe that has something to do with Oracle, so you
should find a newsgroup that deals with Oracle.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-05-2008
CBFalconer <(E-Mail Removed)> writes:

>> Hope someone can help me, please note that at first this might
>> look as if it is posted to the wrong group but if you ignore the
>> specifics I think it is general pointer referencing issue.
>>
>> I am building a plug-in library and is passed, according to the
>> documentation the following;

<snip>
> You are definitely on the wrong group. We deal with standard C,
> and things programmable in standard C.


That does not seem to be the case. For example, you discussed your
allocator here and I doubt that is programmable in standard C.

> You have omitted the source
> of the "OCI environment", without which there is no answer on this
> newsgroup.


Enough has (now) been posted to suggest an answer that is topical --
the OP's function does not match the prototype used to call it.

> I believe that has something to do with Oracle, so you
> should find a newsgroup that deals with Oracle.


Yes, I agree. The OP will probably get better answers in an Oracle
group, provided there is one populated with good C programmers.

--
Ben.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-05-2008
Ben Bacarisse wrote:
> CBFalconer <(E-Mail Removed)> writes:
>

.... snip ...
>
>> You are definitely on the wrong group. We deal with standard C,
>> and things programmable in standard C.

>
> That does not seem to be the case. For example, you discussed your
> allocator here and I doubt that is programmable in standard C.


Huh? What is this 'allocator' jazz? One of us is confused.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      08-05-2008
CBFalconer wrote:

> Ben Bacarisse wrote:
>> CBFalconer <(E-Mail Removed)> writes:
>>

> ... snip ...
>>
>>> You are definitely on the wrong group. We deal with standard C,
>>> and things programmable in standard C.

>>
>> That does not seem to be the case. For example, you discussed your
>> allocator here and I doubt that is programmable in standard C.

>
> Huh? What is this 'allocator' jazz? One of us is confused.


Nmalloc presumably.

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-05-2008
CBFalconer <(E-Mail Removed)> writes:

> Ben Bacarisse wrote:
>> CBFalconer <(E-Mail Removed)> writes:
>>

> ... snip ...
>>
>>> You are definitely on the wrong group. We deal with standard C,
>>> and things programmable in standard C.

>>
>> That does not seem to be the case. For example, you discussed your
>> allocator here and I doubt that is programmable in standard C.

>
> Huh? What is this 'allocator' jazz? One of us is confused.


I agree.

--
Ben.
 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      08-05-2008
On Tue, 5 Aug 2008 03:19:23 -0700 (PDT), bcpkh
<(E-Mail Removed)> wrote:

snip

>Unfortunately I don't call the function, the library that this
>function sits in, an implementation of a published interface, gets
>called by the process that loads the library, access to this
>application is not possible.
>
>Below a cut and paste from the supplied header;
>
>void init(GER_t *pStatus,
> void *ociEnvInfo[],
> OMinfo_t *pInfo);
>
>init gets called by the 'parent' process once when it starts and I
>need to use the passed DB info to interact with the database.


Now that you have shown us the true signature of the function,
everything you coded before invokes undefined behavior and the
previous recommendations you received from this group were based on a
false assumption that led, for the most part, to undefined behavior.

When you code your function to match this signature, statements of the
form
envhp = ociEnvInfo[0];
svchp = ociEnvInfo[1];
will be both syntactically and logically correct as long as the target
variables have the correct type.

What you do with them as well as what you do with the other parameters
needs to be discussed in a topical newsgroup (someone mentioned
Oracle). Once you know what to do with them, questions about how to
do it in standard C can be asked here but odds are the real expertise
will still reside in that topical newsgroup.

--
Remove del for email
 
Reply With Quote
 
bcpkh
Guest
Posts: n/a
 
      08-06-2008
On Aug 5, 7:23*pm, Barry Schwarz <(E-Mail Removed)> wrote:
> On Tue, 5 Aug 2008 03:19:23 -0700 (PDT), bcpkh
>
> <(E-Mail Removed)> wrote:
>
> snip
>
> >Unfortunately I don't call the function, the library that this
> >function sits in, an implementation of a published interface, gets
> >called by the process that loads the library, access to this
> >application is not possible.

>
> >Below a cut and paste from the supplied header;

>
> >void init(GER_t *pStatus,
> > * * * * * * void *ociEnvInfo[],
> > * * * * * * OMinfo_t *pInfo);

>
> >init gets called by the 'parent' process once when it starts and I
> >need to use the passed DB info to interact with the database.

>
> Now that you have shown us the true signature of the function,
> everything you coded before invokes undefined behavior and the
> previous recommendations you received from this group were based on a
> false assumption that led, for the most part, to undefined behavior.
>
> When you code your function to match this signature, statements of the
> form
> * * envhp = ociEnvInfo[0];
> * * svchp = ociEnvInfo[1];
> will be both syntactically and logically correct as long as the target
> variables have the correct type.
>
> What you do with them as well as what you do with the other parameters
> needs to be discussed in a topical newsgroup (someone mentioned
> Oracle). *Once you know what to do with them, questions about how to
> do it in standard C can be asked here but odds are the real expertise
> will still reside in that topical newsgroup.
>
> --
> Remove del for email


Thank you for all the replies and suggestions, like I said might be
the wrong group but I did receive new insight into my problem. Thanks.

B
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the difference between void proba(); and void proba(void); ??? PencoOdStip@gmail.com C++ 1 05-23-2007 07:12 PM
what is the difference, void func(void) and void fucn() noblesantosh@yahoo.com C Programming 5 07-22-2005 04:38 PM
void pointers & void function pointers Peter Goddard C Programming 3 05-16-2005 09:44 PM
"void Method()" vs "void Method(void)" Ollej Reemt C++ 7 04-22-2005 03:47 AM
`void **' revisited: void *pop(void **root) Stig Brautaset C Programming 15 10-28-2003 09:03 AM



Advertisments