|
|
|
|
|
|
| Author |
Message |
JKop
*nix forums Guru Wannabe
Joined: 16 Sep 2005
Posts: 258
|
 Posted: Mon May 15, 2006 11:45 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
| Quote: | But this still won't work:
X *x = new X;
long y = (long)x;
Still have ptr value of x.
What the OP thinks is happening is not possible in either language.
|
I haven't read the rest of the thread, so I don't know what's being
discussed.
X &x = *new X;
long y = x;
-Tomás |
|
| Back to top |
|
 |
pete
*nix forums Guru
Joined: 09 Apr 2005
Posts: 1757
|
| Posted: Mon May 15, 2006 8:54 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
Jack Daly wrote:
| Quote: |
On Sun, 14 May 2006 15:24:37 GMT, Howard Gardner <hgardner@rawbw.com
wrote:
Jack Daly wrote:
I think Richard Heathfield's post (up the thread) is plausible:
in bar,
the vendor is c-casting a long to a dummyTag *, which he then passes
back to you.
Yes, I'm afraid that I missed that. This would be plausible, except
that dummyTag* has real functionality. I can pass a dummyTag* back to
the library to get it to do clever things with the signal. This would
be impossible if it was simply an integer giving the current value of
the signal; it must actually be an object describing a signal.
So, it seems to me that the library is actually C++, and 'bar' has a
copy assignment operator which returns a long. However, the compiler
can't and doesn't know this, so presumably all the magic (or the
error) is in the gnu linker. I wouldn't have expected this to be
possible.
|
The conversion of a pointer type to an integer type
is implementation defined.
What does your implementaion's documentation say?
--
pete |
|
| Back to top |
|
|
Tom Widmer
*nix forums addict
Joined: 21 Mar 2005
Posts: 93
|
| Posted: Mon May 15, 2006 4:46 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
Jack Daly wrote:
| Quote: | On Sun, 14 May 2006 18:36:35 GMT, Keith Thompson <kst-u@mib.org
wrote:
Jack Daly <jd1033@yahoo.com> writes:
wibble = (long)bar(); // shouldn't be possible, but...
printf("wibble is %d\n", wibble); // works!!
}
Is this possible in C? Or does the vendor library have to be C++? If
it is C++, how does this work? I'm compiling with gcc and I can't see
how this module could interface with a C++ class with overloaded
access routines.
You're assuming that the code might be C++ because you think it's
doing "overloading". You've misunderstood the meaning of the term.
Ok, to be more specific: I'm postulating that the vendor has supplied
a C++ library which has (at least) two copy assignment operators:
long operator=(const bar& rhs) {...}
bar* operator=(const bar& rhs) {...}
|
That isn't possible in C++ - you can't overload assignment for built in
types. Nor can you overload the type conversion operator for pointers.
| Quote: | Somehow, this C code has linked with the C++ library and the
assignment 'wibble = (long)bar()' is using the first operator.
|
I'm afraid this isn't possible - C++ doesn't do what you are talking
about anyway, and in any case it would require the compiler, not linker.
| Quote: | The code you posted is simply converting an expression of one type
(dummy, a pointer type) to another type (long). This is perfectly
legal in C (and in C++), but the result won't necessarily be
meaningful.
But it *is* meaningful... that's the whole problem. The interesting
thing is - *why* is it meaningful?
|
Could the number returned not be an index or key into a table? This is
how, for example, Microsoft's opaque HANDLE pointers work.
| Quote: | The function bar() returns a pointer. Possibly the pointer it returns
is obtained by converting an integer value to the pointer type. The
caller then converts from a pointer type back to an integer type.
This is a dangerously non-portable thing to do -- but sometimes
dangerously non-portable code is what's needed to do the job.
See my reply to Howard - I don't think this is possible. The value
returned by the vendor's 'bar' is, in normal circumstances, meant to
be a real object pointer describing a complex signal - you can pass it
back to the vendor's library, and do complicated things with it.
|
It need not be a valid pointer for that. What happens if you print out
the pointer value, e.g.
printf("wibble is %p\n", (void*)wibble);
| Quote: | No, it's getting a real and valid result - see my two previous
replies. There's no chance that the pointer could display as the
expected current value of the signal (the 4 values it's displaying are
2, 18, 0, and 0, which are exactly correct).
|
What do those values represent?
Tom |
|
| Back to top |
|
|
Jack Daly
*nix forums beginner
Joined: 14 May 2006
Posts: 5
|
| Posted: Mon May 15, 2006 4:03 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
On Sun, 14 May 2006 18:36:35 GMT, Keith Thompson <kst-u@mib.org>
wrote:
| Quote: | Jack Daly <jd1033@yahoo.com> writes:
wibble = (long)bar(); // shouldn't be possible, but...
printf("wibble is %d\n", wibble); // works!!
}
Is this possible in C? Or does the vendor library have to be C++? If
it is C++, how does this work? I'm compiling with gcc and I can't see
how this module could interface with a C++ class with overloaded
access routines.
You're assuming that the code might be C++ because you think it's
doing "overloading". You've misunderstood the meaning of the term.
|
Ok, to be more specific: I'm postulating that the vendor has supplied
a C++ library which has (at least) two copy assignment operators:
long operator=(const bar& rhs) {...}
bar* operator=(const bar& rhs) {...}
Somehow, this C code has linked with the C++ library and the
assignment 'wibble = (long)bar()' is using the first operator.
| Quote: | The code you posted is simply converting an expression of one type
(dummy, a pointer type) to another type (long). This is perfectly
legal in C (and in C++), but the result won't necessarily be
meaningful.
|
But it *is* meaningful... that's the whole problem. The interesting
thing is - *why* is it meaningful?
| Quote: | The function bar() returns a pointer. Possibly the pointer it returns
is obtained by converting an integer value to the pointer type. The
caller then converts from a pointer type back to an integer type.
This is a dangerously non-portable thing to do -- but sometimes
dangerously non-portable code is what's needed to do the job.
|
See my reply to Howard - I don't think this is possible. The value
returned by the vendor's 'bar' is, in normal circumstances, meant to
be a real object pointer describing a complex signal - you can pass it
back to the vendor's library, and do complicated things with it.
That's how the vendor's docs describe it, and that's how everybody
else uses the library, including my departed colleague, except in
these 4 cases that I'm trying to figure out. I'd ignore it except that
I think there's something to be learnt here.
| Quote: | It's also possible that the value returned by bar() is a valid pointer
value, to be used only by the vendor's code, and your function foo()
is abusing it by converting it to long and getting a meaningless
result.
|
No, it's getting a real and valid result - see my two previous
replies. There's no chance that the pointer could display as the
expected current value of the signal (the 4 values it's displaying are
2, 18, 0, and 0, which are exactly correct).
Jack |
|
| Back to top |
|
|
Jack Daly
*nix forums beginner
Joined: 14 May 2006
Posts: 5
|
| Posted: Mon May 15, 2006 3:43 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
On Sun, 14 May 2006 15:24:37 GMT, Howard Gardner <hgardner@rawbw.com>
wrote:
| Quote: | Jack Daly wrote:
I think Richard Heathfield's post (up the thread) is plausible: in bar,
the vendor is c-casting a long to a dummyTag *, which he then passes
back to you.
|
Yes, I'm afraid that I missed that. This would be plausible, except
that dummyTag* has real functionality. I can pass a dummyTag* back to
the library to get it to do clever things with the signal. This would
be impossible if it was simply an integer giving the current value of
the signal; it must actually be an object describing a signal.
So, it seems to me that the library is actually C++, and 'bar' has a
copy assignment operator which returns a long. However, the compiler
can't and doesn't know this, so presumably all the magic (or the
error) is in the gnu linker. I wouldn't have expected this to be
possible.
Jack |
|
| Back to top |
|
|
Keith Thompson
*nix forums Guru
Joined: 28 Feb 2005
Posts: 5173
|
| Posted: Sun May 14, 2006 6:36 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
Jack Daly <jd1033@yahoo.com> writes:
| Quote: | I've inherited some code which uses an undocumented feature of a
third-party vendor's library. Essentially, this vendor has kept the
details of an interface struct secret, but we can pass a pointer to
this struct to other vendor routines. The struct describes a complex
time-varying object, but it basically boils down to an integer, and
there are access routines to get to the current value of this integer.
My problem is:
1) Our code is C, and the vendor's library is, I think, also C
2) This undocumented feature allowed my (ex) colleague's code to read
the integer directly from the pointer. In other words, the return
value is somehow overloaded.
How is this possible? My only thought is that the vendor library is
actually C++, but even if it is, I still can't see how to make this
work.
Here's a test program that shows this (it compiles Ok as a stand-alone
routine):
#include <stdio.h
typedef struct dummyTag * dummy; // secret vendor struct
extern dummy bar(void); // vendor's access routine
void foo(void) {
int wibble;
wibble = (long)bar(); // shouldn't be possible, but...
printf("wibble is %d\n", wibble); // works!!
}
Is this possible in C? Or does the vendor library have to be C++? If
it is C++, how does this work? I'm compiling with gcc and I can't see
how this module could interface with a C++ class with overloaded
access routines.
|
[Followups redirected to comp.lang.c.]
You're assuming that the code might be C++ because you think it's
doing "overloading". You've misunderstood the meaning of the term.
Overloading means using the same name for two different functions or
operators. In C++, you can have two different functions both named
"foo", as long as they take different types of arguments. When the
compiler sees a call to foo(), it determines which function to call by
looking at the arguments. Likewise, you can overload operators as
functions; the C++ standard library does this to use the shift
operators "<<" and ">>" for I/O. When the compiler sees
(cout << "hello"), it decides what to do based on the types of the
operands.
None of this is supported in C, and none of this has anything to do
with the code you posted.
The code you posted is simply converting an expression of one type
(dummy, a pointer type) to another type (long). This is perfectly
legal in C (and in C++), but the result won't necessarily be
meaningful.
Another suspicious thing in the code you posted is that the result of
bar() is converted to long, and then assigned to an int. There may or
may not be a good reason to do that.
The function bar() returns a pointer. Possibly the pointer it returns
is obtained by converting an integer value to the pointer type. The
caller then converts from a pointer type back to an integer type.
This is a dangerously non-portable thing to do -- but sometimes
dangerously non-portable code is what's needed to do the job.
It's also possible that the value returned by bar() is a valid pointer
value, to be used only by the vendor's code, and your function foo()
is abusing it by converting it to long and getting a meaningless
result. (If you're determined to do something dangerous, C won't
necessarily stop you.)
If you just want to display the value returned by bar(), you can use
printf's "%p" format:
void foo(void)
{
dummy wibble = bar();
printf("wibble is %p\n", (void*)wibble);
}
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. |
|
| Back to top |
|
|
Nils O. Selåsdsal
*nix forums addict
Joined: 05 Nov 2005
Posts: 85
|
| Posted: Sun May 14, 2006 4:39 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
Jack Daly wrote:
| Quote: | #include <stdio.h
typedef struct dummyTag * dummy; // secret vendor struct
extern dummy bar(void); // vendor's access routine
void foo(void) {
int wibble;
wibble = (long)bar(); // shouldn't be possible, but...
printf("wibble is %d\n", wibble); // works!!
}
Is this possible in C? Or does the vendor library have to be C++? If
Your code converts a pointer value to a long. Looks ok. |
(C doesn't give you much guarantee that converted value makes any
sense, hough perhaps it contains the memory address of the
struct dummyTag pointer on your system).
What is it exactly you think "works" btw ? |
|
| Back to top |
|
|
Howard Gardner
*nix forums beginner
Joined: 03 Feb 2005
Posts: 25
|
| Posted: Sun May 14, 2006 3:24 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
Jack Daly wrote:
| Quote: | If this was C, then the printf should be printing an address, but it
actually prints (from memory, for 4 calls) 2, 18, 0, 0, which is
exactly what I'd expect for these 4 VHDL signals, which are two
integers with values 2 and 18, and two booleans with value false.
So, I don't think it can be C, even buggy C. On the other hand, I
don't see how it can be C++, for 2 reasons:
1 - this compilation unit includes nothing which describes the
internals of 'struct dummyTag'. I didn't think this was possible in
C++ - doesn't the compiler need to know, when compiling this file,
that 'struct dummyTag' is a class which can be read to return a long?
2 - I can't see how I can compile with gcc, rather than g++.
Thanks -
Jack
|
I think Richard Heathfield's post (up the thread) is plausible: in bar,
the vendor is c-casting a long to a dummyTag *, which he then passes
back to you.
The vendor is very clearly saying "keep your mitts off of this thing".
You're ex-colleague is very clearly saying "get stuffed, vendor"  |
|
| Back to top |
|
|
Jack Daly
*nix forums beginner
Joined: 14 May 2006
Posts: 5
|
| Posted: Sun May 14, 2006 3:11 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
On Sun, 14 May 2006 12:47:05 GMT, pete <pfiland@mindspring.com> wrote:
| Quote: | If you convert the address of a struct
to a pointer to the type of it's first member,
then that result will be a pointer to the first member of the struct.
If that first member were an integer,
then that's what I would mean by being able to access
an integer directly from a pointer to the struct.
|
Hmmm.. but the code casts to a long, rather than a long*:
| Quote: | void foo(void) {
int wibble;
wibble = (long)bar(); // shouldn't be possible, but...
printf("wibble is %d\n", wibble); // works!!
}
|
If this was C, then the printf should be printing an address, but it
actually prints (from memory, for 4 calls) 2, 18, 0, 0, which is
exactly what I'd expect for these 4 VHDL signals, which are two
integers with values 2 and 18, and two booleans with value false.
So, I don't think it can be C, even buggy C. On the other hand, I
don't see how it can be C++, for 2 reasons:
1 - this compilation unit includes nothing which describes the
internals of 'struct dummyTag'. I didn't think this was possible in
C++ - doesn't the compiler need to know, when compiling this file,
that 'struct dummyTag' is a class which can be read to return a long?
2 - I can't see how I can compile with gcc, rather than g++.
Thanks -
Jack |
|
| Back to top |
|
|
Jack Daly
*nix forums beginner
Joined: 14 May 2006
Posts: 5
|
| Posted: Sun May 14, 2006 2:59 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
On Sun, 14 May 2006 11:56:46 +0000, Richard Heathfield
<invalid@invalid.invalid> wrote:
| Quote: | Well, what you've done is converted a pointer into an integer, which is
legal if you cast it. The resulting information is normally pretty
meaningless, but you seem to think there is meaning in the value you get.
What makes you think that?
|
I didn't go into the details, because it's pretty complicated. My C
program is talking to a VHDL program, with signals communicating
between the two. A 'signal' is basically an electronic level on a
wire, but the complications include the fact that it may have an
enumerated value, its value varies over time, and a record of required
future transactions is recorded with the signal. The vendor library
provides a pointer to the signal object without disclosing what the
details of the object are, and also provides various routines to
retrieve the current value of the signal as an integer.
So, I was pretty surprised when I found this code that manages to
correctly read the current value of a signal from a pointer typecast.
Actually, it reads 4 VHDL signals, of two different types, and has got
the right result in all cases.
The code isn't even dereferencing the pointer, so it looked to me like
C++ overloading. But, I can't understand how it does this without (a)
being compiled as C++, and (b) having the appropriate headers
declaring the 'secret' struct.
Thanks -
Jack |
|
| Back to top |
|
|
pete
*nix forums Guru
Joined: 09 Apr 2005
Posts: 1757
|
| Posted: Sun May 14, 2006 12:47 pm Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
Jack Daly wrote:
| Quote: |
I've inherited some code which uses an undocumented feature of a
third-party vendor's library. Essentially, this vendor has kept the
details of an interface struct secret, but we can pass a pointer to
this struct to other vendor routines. The struct describes a complex
time-varying object, but it basically boils down to an integer, and
there are access routines to get to the current value of this integer.
2) This undocumented feature allowed my (ex) colleague's code to read
the integer directly from the pointer. In other words, the return
value is somehow overloaded.
How is this possible?
|
If I had a struct
where I could read an integer directly from a pointer to the struct,
it would mean something different from what you described,
which I snipped.
If you convert the address of a struct
to a pointer to the type of it's first member,
then that result will be a pointer to the first member of the struct.
If that first member were an integer,
then that's what I would mean by being able to access
an integer directly from a pointer to the struct.
I'm reading this crosspost from clc.
--
pete |
|
| Back to top |
|
|
neutron*star
*nix forums Guru
Joined: 21 Feb 2005
Posts: 2039
|
| Posted: Sun May 14, 2006 11:56 am Post subject:
Re: Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
[Followups set to comp.lang.c]
Jack Daly said:
| Quote: | I've inherited some code which uses an undocumented feature of a
third-party vendor's library. Essentially, this vendor has kept the
details of an interface struct secret, but we can pass a pointer to
this struct to other vendor routines. The struct describes a complex
time-varying object, but it basically boils down to an integer, and
there are access routines to get to the current value of this integer.
|
In short, you have an opaque type. So far so good.
| Quote: | My problem is:
1) Our code is C, and the vendor's library is, I think, also C
|
That's not a problem. That's an opportunity. :-)
| Quote: | 2) This undocumented feature allowed my (ex) colleague's code to read
the integer directly from the pointer. In other words, the return
value is somehow overloaded.
|
Well, perhaps there is a simpler explanation.
| Quote: | How is this possible? My only thought is that the vendor library is
actually C++, but even if it is, I still can't see how to make this
work.
Here's a test program that shows this (it compiles Ok as a stand-alone
routine):
#include <stdio.h
typedef struct dummyTag * dummy; // secret vendor struct
extern dummy bar(void); // vendor's access routine
void foo(void) {
int wibble;
wibble = (long)bar(); // shouldn't be possible, but...
printf("wibble is %d\n", wibble); // works!!
|
Well, what you've done is converted a pointer into an integer, which is
legal if you cast it. The resulting information is normally pretty
meaningless, but you seem to think there is meaning in the value you get.
What makes you think that?
If that really is the value that the secret struct stores, then presumably
it's written something like this:
dummy bar(void)
{
return (dummy)secretnumber;
}
| Quote: | }
Is this possible in C?
|
I don't think you've yet established that overloading is occurring.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously) |
|
| Back to top |
|
|
Jack Daly
*nix forums beginner
Joined: 14 May 2006
Posts: 5
|
| Posted: Sun May 14, 2006 11:39 am Post subject:
Overloaded vendor library routine: is this C++? Or very clever C?
|
|
|
I've inherited some code which uses an undocumented feature of a
third-party vendor's library. Essentially, this vendor has kept the
details of an interface struct secret, but we can pass a pointer to
this struct to other vendor routines. The struct describes a complex
time-varying object, but it basically boils down to an integer, and
there are access routines to get to the current value of this integer.
My problem is:
1) Our code is C, and the vendor's library is, I think, also C
2) This undocumented feature allowed my (ex) colleague's code to read
the integer directly from the pointer. In other words, the return
value is somehow overloaded.
How is this possible? My only thought is that the vendor library is
actually C++, but even if it is, I still can't see how to make this
work.
Here's a test program that shows this (it compiles Ok as a stand-alone
routine):
#include <stdio.h>
typedef struct dummyTag * dummy; // secret vendor struct
extern dummy bar(void); // vendor's access routine
void foo(void) {
int wibble;
wibble = (long)bar(); // shouldn't be possible, but...
printf("wibble is %d\n", wibble); // works!!
}
Is this possible in C? Or does the vendor library have to be C++? If
it is C++, how does this work? I'm compiling with gcc and I can't see
how this module could interface with a C++ class with overloaded
access routines.
Many thanks -
Jack |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Wed Jan 07, 2009 5:22 pm | All times are GMT
|
|
Watch Anime Free Online | Auto Loan | Problem Mortgage | Loans | Bankruptcy
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
C
