Beginners questions regarding argument transferral and finding all available functions (linux)

[R.Wieser]

Hello all,

Fair warning: I'm a novice in regard to using C++ (GCC) *and* using linux
(lubuntu to be exact). If this is not the newsgroup to be asking questions
like the below than please advice which newsgroup(s) to use instead.

- - - - - -
First problem, C++ related:

I need to transfer the address of a structure to a function, and have only
be able to find a hackish solution for it. The problem is that the variable
I've got is actually a pointer, and I have no idea how to dereference it.

The variable declaration and initialisation in case:

struct hostent *server;
server = gethostbyname(argv[1]);

Now I want to transfer the address stored in the "server" variable to a
function. The only way I was able to do that was to refer to the first (and
in this case only) field in that structure:

foobar( (unsigned char*) server->h_addr, ... )

I read somewhere that I could use (*server) , but trying it ( (unsigned
char*) (*server) ) gave a compile-time error.

In short: How do I dereference that "server" variable so the function
receives a pointer to the structure ?

- - - - - -
Second problem, Linux related:

As someone wo has spend quite some time on Windows I'm rather accustomed
being able to pick a DLL and look inside it to see which functions it
exposes that I can use (yeah, I still have to generate a library from it and
find the function declarations, but thats not the point).

I have no idea how to do the same under Linux (and/or how to convert the
found functions (system calls ?) to something I can use in C++ ).

To be honest, I have no idea if the above is even feasible for C++ (GCC)
under linux.

I did find an example using "nm", but that only showed the contents of the
.o (library) file, and only if the info was not stripped.

I also tried that on the full /usr directory, but could not even find
"fprint" (found buf_fprint" and "str_fprint" though).


And now I'm on a roll asking questions, one thing I did not expect was to
find multiple (sometimes over 10) same-named header files , most often of
different sizes. Whats the idea behind that, and how should I know which
one of those to include ?

Regards,
Rudy Wieser

[Richard]

[Please do not mail me a copy of your followup]

"R.Wieser" <add...@not.available> spake the secret code
<57c4895a$0$871$e4fe...@news.xs4all.nl> thusly:

>I need to transfer the address of a structure to a function, and have only
>be able to find a hackish solution for it. The problem is that the variable
>I've got is actually a pointer, and I have no idea how to dereference it.
>
>The variable declaration and initialisation in case:
>
>struct hostent *server;
>server = gethostbyname(argv[1]);

Here 'server' is a variable holding the address of a 'hostent'
structure. server *is* the address. If you want to pass the address
of the structure to another function, just use the variable 'server'.

It sometimes helps if you read the declarations from right to left
out loud:

struct hostent *server;

"server is a pointer to a hostent structure"

--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Vir Campestris]

On 29/08/2016 20:16, R.Wieser wrote:
> As someone wo has spend quite some time on Windows I'm rather accustomed
> being able to pick a DLL and look inside it to see which functions it
> exposes that I can use (yeah, I still have to generate a library from it and
> find the function declarations, but thats not the point).
>
> I have no idea how to do the same under Linux (and/or how to convert the
> found functions (system calls ?) to something I can use in C++ ).

As someone who started using Linux not many years ago after many years
of other systems, which included a _lot_ of Windows - I've almost never
had to do that on Windows. If someone wants you to use their library
they'll provide a .h file, and you include that. Then you link against
the library. It's always just worked on Linux... though I suppose I've
mostly been the library supplier, not the app developer.

Andy

[Öö Tiib]

On Monday, 29 August 2016 22:17:10 UTC+3, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "R.Wieser" <add...@not.available> spake the secret code
> <57c4895a$0$871$e4fe...@news.xs4all.nl> thusly:
>
> >I need to transfer the address of a structure to a function, and have only
> >be able to find a hackish solution for it. The problem is that the variable
> >I've got is actually a pointer, and I have no idea how to dereference it.
> >
> >The variable declaration and initialisation in case:
> >
> >struct hostent *server;
> >server = gethostbyname(argv[1]);
>
> Here 'server' is a variable holding the address of a 'hostent'
> structure. server *is* the address. If you want to pass the address
> of the structure to another function, just use the variable 'server'.
>
> It sometimes helps if you read the declarations from right to left
> out loud:
>
> struct hostent *server;
>
> "server is a pointer to a hostent structure"

Yes, but it seemed that he wanted host addresses as strings from that
hostent structure. Something like:

for ( char **it = server->h_addr_list; *it != nullptr; ++it )
{
foobar( *it, ... );
...
}

Of course, I may be wrong, it is not clear what programming language
and in what way he used on Windows.

[Paavo Helde]

On 29.08.2016 22:16, R.Wieser wrote:
> Hello all,
>
> Fair warning: I'm a novice in regard to using C++ (GCC) *and* using linux
> (lubuntu to be exact). If this is not the newsgroup to be asking questions
> like the below than please advice which newsgroup(s) to use instead.
>
> - - - - - -
> First problem, C++ related:
>
> I need to transfer the address of a structure to a function, and have only
> be able to find a hackish solution for it. The problem is that the variable
> I've got is actually a pointer, and I have no idea how to dereference it.
>
> The variable declaration and initialisation in case:
>
> struct hostent *server;
> server = gethostbyname(argv[1]);
>
> Now I want to transfer the address stored in the "server" variable to a
> function. The only way I was able to do that was to refer to the first (and
> in this case only) field in that structure:
>
> foobar( (unsigned char*) server->h_addr, ... )
>
> I read somewhere that I could use (*server) , but trying it ( (unsigned
> char*) (*server) ) gave a compile-time error.
>
> In short: How do I dereference that "server" variable so the function
> receives a pointer to the structure ?

No C++ here so far, this is all pure C. Anyway, if you have troubles
with basic syntax like this, then I suggest to start with a proper
textbook or tutorial. First you should make up your mind what language
do you want to learn, C or C++, these are two totally different
languages and raw pointers like above hostent* do not actually appear
very often in proper C++ programs.

>
> - - - - - -
> Second problem, Linux related:
>
> As someone wo has spend quite some time on Windows I'm rather accustomed
> being able to pick a DLL and look inside it to see which functions it
> exposes that I can use (yeah, I still have to generate a library from it and
> find the function declarations, but thats not the point).
>
> I have no idea how to do the same under Linux (and/or how to convert the
> found functions (system calls ?) to something I can use in C++ ).

This is very counter-productive, it is much easier and safer to use
documentation. But anyway, first google search shows there are things
like objdump and readelf which might be useful for examining so-s.

>
> To be honest, I have no idea if the above is even feasible for C++ (GCC)
> under linux.
>
> I did find an example using "nm", but that only showed the contents of the
> .o (library) file, and only if the info was not stripped.
>
> I also tried that on the full /usr directory, but could not even find
> "fprint" (found buf_fprint" and "str_fprint" though).

Maybe because there is no such thing like fprint? There are printf and
fprintf though, google

man fprintf

for example.

>
>
> And now I'm on a roll asking questions, one thing I did not expect was to
> find multiple (sometimes over 10) same-named header files , most often of
> different sizes. Whats the idea behind that, and how should I know which
> one of those to include ?

Documentation? For C++ see e.g.

https://isocpp.org/faq
http://en.cppreference.com/w/
http://www.cplusplus.com/

HTH
Paavo

[jacobnavia]

Le 29/08/2016 à 21:16, R.Wieser a écrit :
> And now I'm on a roll asking questions, one thing I did not expect was to
> find multiple (sometimes over 10) same-named header files , most often of
> different sizes. Whats the idea behind that, and how should I know which
> one of those to include ?

Ahhh welcome to linux. Actually there is no way to know. You can have
different headers if you have installed different compilers or different
versions of the same compiler, or just some hacks that didn't go well
and left some headers... who knows?

Now, you can ask the compiler which headers is it using, if memory
serves gcc had a command line option to show the paths its using.

[Gareth Owen]

jacobnavia <ja...@jacob.remcomp.fr> writes:

> Le 29/08/2016 à 21:16, R.Wieser a écrit :
>> And now I'm on a roll asking questions, one thing I did not expect was to
>> find multiple (sometimes over 10) same-named header files , most often of
>> different sizes. Whats the idea behind that, and how should I know which
>> one of those to include ?

The compiler knows, so you don't have to. If you want to include
stdio.h, use

#include <stdio.h>

> Ahhh welcome to linux. Actually there is no way to know.

There are lots of ways to know. The package manager will know,

> You can have different headers if you have installed different
> compilers or different versions of the same compiler, or just some
> hacks that didn't go well and left some headers... who knows?

Ask the package manager. The package manager knows.

Actually, none of Jacob's "answers" are the most likely - what he knows
about linux couldn't fill a hat. Doesn't stop him having opinions, of
course.

The most likely answer is that they all belong to one compiler.
On my system I have

/usr/include/stdio.h
/usr/include/c++/4.8/tr1/stdio.h
/usr/include/x86_64-linux-gnu/bits/stdio.h

all of which belong to the gcc version I have installed. (I also have
the ARM-versions for the ARM compiler, in folders with names like
arm-xilinx-eabi).

When I do
#include <stdio.h>
the compiler does the right thing.

[R.Wieser]

Gareth,

> The compiler knows, so you don't have to. If you want
> to include stdio.h, use
>
> #include <stdio.h>

Thats exactly the problem. How do I know that I need to include stdio.h and
not foobar.h to be able to use a certain function ?

> There are lots of ways to know. The package manager will know,

What has the packet manager to do with anything ? *I'm* writing a program,
and *I* need to add the correct includes.

Regards,
Rudy Wieser


- Origional message:
Gareth Owen <gwo...@gmail.com> schreef in berichtnieuws
87wpiyo...@gmail.com...

[R.Wieser]

Andy,

> As someone who started using Linux not many years ago
> after many years of other systems, which included a _lot_
> of Windows - I've almost never had to do that on Windows

:-) Who said I was using C{something} on Windows :-p

But consider my request both as an attempt to get a bit more knowledge about
how stuff works, as well as creating independance from the "they" that
should make the header and library files for me.

But, in the first place its only an attempt to generate a list with all
available functions that I can use in a program. Currently the only way to
know if a certain function (that I know exists in Windows) is available in
gcc/linux is by stumbling over it in an example program. And that isn't
acceptable to me.

Regards,
Rudy Wieser


-- Origional message:
Vir Campestris <vir.cam...@invalid.invalid> schreef in berichtnieuws
4vSdnVhKxMTWCFnK...@brightview.co.uk...

[R.Wieser]

Paavo,

> Anyway, if you have troubles with basic syntax like this,
> then I suggest to start with a proper textbook or tutorial.

Thanks, but al you seem to be saying is "go away". Thanks bub.

Is it really so hard to dereference something that it can't be described in
few lines ?

> But anyway, first google search shows there are things
> like objdump and readelf which might be useful for
> examining so-s.

Using 20-20 vision, sure. Mind you, I gave you a fair warning that I'm a
*beginner* (at least in respect to Linux and C{something} ). I *assume*
that library files are the .o files in the "lib" branch, but am not even
sure about that.

Also, how do you think I found that "nm" I spoke of ?

Regards,
Rudy Wieser


-- Origional message:

Paavo Helde <myfir...@osa.pri.ee> schreef in berichtnieuws
vvidnecFA7cvB1nK...@giganews.com...

[R.Wieser]

嘱 Tiib,

> Yes, but it seemed that he wanted host addresses as strings
> from that hostent structure.

Nope, I just want the address of the structure itself. Thats all.

> it is not clear what programming language

I'm not sure myself, but I assume that its C++, seeing that let G++ compile
the sourcecode.

> and in what way he used on Windows.

I didn't. I'm doing it on a Linux variant.

Regards,
Rudy Wieser


-- Origional message

嘱 Tiib <oot...@hot.ee> schreef in berichtnieuws
242b3c44-f5a2-4bed...@googlegroups.com...

[R.Wieser]

jacobnavia,

>Ahhh welcome to linux. Actually there is no way to know.

...

> Now, you can ask the compiler which headers is it using, if
> memory serves gcc had a command line option to show the
> paths its using.

Ah, that makes some sense. I seem to remember having seen something like
that (a reference to a cache of some sort).

Thanks for the hint.

Regards,
Rudy Wieser


-- Origional message:
jacobnavia <ja...@jacob.remcomp.fr> schreef in berichtnieuws
nq28u0$al3$1...@dont-email.me...

[R.Wieser]

Richard,

> Here 'server' is a variable holding the address of a
> 'hostent' structure. server *is* the address.

I'm sorry, but I disagree with you. Just consider the difference between

struct hostent server;

and

struct hostent *server;

I regard your above statement true for the first, not the latter. As far as
I can tell for the latter "server" is the addres of the variable which holds
the address to the "hostent" structure (hence the need for dereferencing).

Regards,
Rudy Wieser


-- Origional message:

Richard <legaliz...@mail.xmission.com> schreef in berichtnieuws
nq21nb$ead$1...@news.xmission.com...

[Ian Collins]

On 08/30/16 09:17 PM, R.Wieser wrote:
> Gareth,
>
>> The compiler knows, so you don't have to. If you want
>> to include stdio.h, use
>>
>> #include <stdio.h>
>
> Thats exactly the problem. How do I know that I need to include stdio.h and
> not foobar.h to be able to use a certain function ?

man <certain function>

--
Ian

[R.Wieser]

Funny:

> In short: How do I dereference that "server" variable so
> the function receives a pointer to the structure ?

Odd: several replies, but none that actually told me how its done. Is it
some deep-dark secret that only masters of the trade are allowed to know ?

And for some of you guys here: don't try to second-guess what I'm after.
I'm in the habit of trying to ask my questions as exact as I can, needing it
to have *it* answered. (that does not mean that I do not appreciate further
hints in the same direction though!)

Do I really need to waste hours googeling hoping I will stumble over the
(most likely rather simple) answer ?

Regards,
Rudy Wieser

[Paavo Helde]

On 30.08.2016 11:57, R.Wieser wrote:
> Paavo,
>
>> Anyway, if you have troubles with basic syntax like this,
>> then I suggest to start with a proper textbook or tutorial.
>
> Thanks, but al you seem to be saying is "go away". Thanks bub.

I'm just saying that it is not productive to learn language basics from
a newsgroup, it's too tedious and chaotic. If you get stuck with some
more concrete problem then you can always come back here, and preferably
with a real code sample, not a vague description using wrong terms.

> Is it really so hard to dereference something that it can't be described in
> few lines ?

You wanted to get a pointer, that's basically the opposite of
dereferencing. Besides, your original question was answered immediately
by Richard so there was no need to repeat this answer.

If you have a pointer called 'server', then for dereferencing it you use
'*server' or 'server->', depending on the exact usage. For passing the
pointer without dereferencing you just use 'server'.

>
>> But anyway, first google search shows there are things
>> like objdump and readelf which might be useful for
>> examining so-s.
>
> Using 20-20 vision, sure. Mind you, I gave you a fair warning that I'm a
> *beginner* (at least in respect to Linux and C{something} ). I *assume*
> that library files are the .o files in the "lib" branch, but am not even
> sure about that.

No, library files are called .so and .a. I'm sorry I mentioned objdump
and readelf, I should have just said that examining the library symbols
is a rare need and definitely not something a beginner should do at all.

Cheers
Paavo

[Paavo Helde]

On 30.08.2016 12:17, R.Wieser wrote:
> Gareth,
>
>> The compiler knows, so you don't have to. If you want
>> to include stdio.h, use
>>
>> #include <stdio.h>
>
> Thats exactly the problem. How do I know that I need to include stdio.h and
> not foobar.h to be able to use a certain function ?

From the function documentation of course. How else could you know how
to use the function at all?

If you want to use fprintf, then type man fprintf in the Linux command
line or google search and the correct #include is among the first things
it says:

fprintf(3) - Linux man page
Name

printf, fprintf, sprintf, snprintf, vprintf, vfprintf, vsprintf,
vsnprintf - formatted output conversion

Synopsis

#include <stdio.h>

int printf(const char *format, ...);
int fprintf(FILE *stream, const char *format, ...);

NRHTH
Paavo

[Öö Tiib]

On Tuesday, 30 August 2016 12:14:44 UTC+3, R.Wieser wrote:
> Richard,
>
> > Here 'server' is a variable holding the address of a
> > 'hostent' structure. server *is* the address.
>
> I'm sorry, but I disagree with you. Just consider the difference between
>
> struct hostent server;
>
> and
>
> struct hostent *server;
>
> I regard your above statement true for the first, not the latter. As far as
> I can tell for the latter "server" is the addres of the variable which holds
> the address to the "hostent" structure (hence the need for dereferencing).

Unfortunately you seem to add one indirection that isn't there. In former
'server' is variable that contains all data of structure 'hostent'. To get
address to it you need to type '&server'.

In latter 'server' is pointer variable that can contain address of structure
'hostent'. When it is pointing at actual 'hostent' then you may dereference it.
For dereferencing you need to type '*server' (or 'server->' if you want access
particular member of it).

[R.Wieser]

Paavo,

> I'm just saying that it is not productive to learn language
> basics from a newsgroup, it's too tedious and chaotic.

Please, let *me* be the judge of that. This is a tiny bit of knowledge,
which, if solved, allows me to progress quite a bit.

> If you get stuck with some more concrete problem ...

I don't know how much more concrete it can become as what I described.

But maybe the following problem casing will help you:

two definitions:

1) struct hostent server1;

2) struct hostent *server2;

For *both* of the above I want to give a pointer to the actual hostent
structure to a function called "foobar", which expects the argument to be of
type unsigned char*.

Describe the calling method for *both*. (I'm rather sure that my answer
lies in the difference between the two).

Concrete enough for you ?

> and preferably with a real code sample, not a vague description ...

Thats what I posted and am using in my code. I'm sorry, but I have no idea
what "code samples" look like in your reality.

> ... using wrong terms.

See below:

> You wanted to get a pointer, that's basically the opposite of
> dereferencing.

And you talk about vague ?

Yes, I want to "get a pointer". But I want to move *towards* the structure,
not *away* from it. And as far as I'm aware thats indeed called
"dereferencing"

> Besides, your original question was answered immediately
> by Richard so there was no need to repeat this answer.

Bull. And if you think otherwise than quote it.

All he did was quoting the first line of my code sample. Yeah, thats
really helpfull. Not.

> then for dereferencing it you use '*server' or 'server->',
> depending on the exact usage

Also bull. Both

foobar( (unsigned char*) *server , ... )

as well as

foobar( (unsigned char*) server-> , ... )

throw a compile-time error (invalid cast for the first, unqualified
identifier for the second). And FYI, I have tried the former before posting
here (didn't think the latter having any chance of succeeding, so I didn't
even try it).

> No, library files are called .so and .a.

Thanks. So, I was looking in the wrong files. That could explain a lot.
:-)

Regards,
Rudy Wieser



-- Origional message:
Paavo Helde <myfir...@osa.pri.ee> schreef in berichtnieuws

_LidnQTXd5SPyVjK...@giganews.com...

[R.Wieser]

Ian,

> man <certain function>

:-\ I had not thought of that.
...

Just tested it, and I had ofcourse (among a few others) to choose a function
which clashes with a console command : write. :-( :-) Any idea what to do
in such cases ?

Regards,
Rudy Wieser


-- Origional message:

Ian Collins <ian-...@hotmail.com> schreef in berichtnieuws
e2l1dg...@mid.individual.net...

[Paavo Helde]

On 30.08.2016 14:34, R.Wieser wrote:
> Paavo,
>
>> I'm just saying that it is not productive to learn language
>> basics from a newsgroup, it's too tedious and chaotic.
>
> Please, let *me* be the judge of that. This is a tiny bit of knowledge,
> which, if solved, allows me to progress quite a bit.

Why are not judging here anything, I express my opinions, you express yours.

>
>> If you get stuck with some more concrete problem ...
>
> I don't know how much more concrete it can become as what I described.
>
> But maybe the following problem casing will help you:
>
> two definitions:
>
> 1) struct hostent server1;
>
> 2) struct hostent *server2;
>
> For *both* of the above I want to give a pointer to the actual hostent
> structure to a function called "foobar", which expects the argument to be of
> type unsigned char*.
>

> Concrete enough for you ?

Yes, that was concrete enough, thank you. Here are the answers to these
questions.

1) foobar(reinterpret_cast<unsigned char*>(&server1));

2) foobar(reinterpret_cast<unsigned char*>(server2));

(side note: this is C++ so you probably need to compile it with g++, not
gcc).

(side note 2: there is no dereferencing here, & is the address-of
operator. The term "dereferencing" has very specific meaning in C and
C++ and if you use it in a C or C++ forum everybody assumes you are
using it in the same meaning.)

>
>> and preferably with a real code sample, not a vague description ...
>
> Thats what I posted and am using in my code. I'm sorry, but I have no idea
> what "code samples" look like in your reality.

A proper code sample is preferably a complete source file including all
the #includes as well as int main(). This makes it easy for other people
to try to compile it and understand where the problems appear.

See e.g.

https://groups.google.com/forum/#!topic/comp.lang.c++/VaDCk_oujMg

[R.Wieser]

嘱 Tiib,

> In former 'server' is variable that contains all data of structure
> 'hostent'. To get address to it you need to type '&server'.

Agreed.

> In latter 'server' is pointer variable that can contain address
> of structure 'hostent'.

Again, agreed.

> When it is pointing at actual 'hostent' then you may dereference it.

YES. How do I do that ?

> For dereferencing you need to type '*server' (or 'server->' if you
> want access particular member of it).

In my first post I indicated I used the latter using the first member of the
structure, but I consider that to be a hack. I also indicated that I tried
"(*server)", and that it gave me a compile-time error.

Any other ideas ?

Regards,
Rudy Wieser


-- Origional message:

嘱 Tiib <oot...@hot.ee> schreef in berichtnieuws

6fe758df-bf42-430f...@googlegroups.com...

[Scott Lurndal]

"R.Wieser" <add...@not.available> writes:

>As someone wo has spend quite some time on Windows I'm rather accustomed
>being able to pick a DLL and look inside it to see which functions it
>exposes that I can use (yeah, I still have to generate a library from it and
>find the function declarations, but thats not the point).

$ nm -D /usr/lib64/libzip.so.2 | grep " T " |more

[Scott Lurndal]

"R.Wieser" <add...@not.available> writes:
>Gareth,
>
>> The compiler knows, so you don't have to. If you want
>> to include stdio.h, use
>>
>> #include <stdio.h>
>
>Thats exactly the problem. How do I know that I need to include stdio.h and
>not foobar.h to be able to use a certain function ?

The man pages are your friend.

$ man -k printf
asprintf (3) - print to allocated string
dprintf (3) - print to a file descriptor
format (n) - Format a string in the style of sprintf
fprintf (3) - formatted output conversion
fprintf (3p) - print formatted output
fwprintf (3) - formatted wide-character output conversion
fwprintf (3p) - print formatted wide-character output
printf (1) - format and print data
printf (1p) - write formatted output
printf (3) - formatted output conversion
printf (3p) - print formatted output
snprintf (3) - formatted output conversion
snprintf (3p) - print formatted output
sprintf (3) - formatted output conversion
sprintf (3p) - print formatted output
swprintf (3) - formatted wide-character output conversion
...

$ man 3 printf | head -20
PRINTF(3) Linux Programmer's Manual PRINTF(3)



NAME

printf, fprintf, sprintf, snprintf, vprintf, vfprintf, vsprintf, vsnprintf - formatted output conversion

SYNOPSIS

#include <stdio.h>

int printf(const char *format, ...);
int fprintf(FILE *stream, const char *format, ...);

int sprintf(char *str, const char *format, ...);
int snprintf(char *str, size_t size, const char *format, ...);

#include <stdarg.h>

int vprintf(const char *format, va_list ap);
int vfprintf(FILE *stream, const char *format, va_list ap);
int vsprintf(char *str, const char *format, va_list ap);

Or you can use the appropriate standard document, for example:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html

[Scott Lurndal]

"R.Wieser" <add...@not.available> writes:
>Ian,
>
>> man <certain function>
>
>:-\ I had not thought of that.
>...
>
>Just tested it, and I had ofcourse (among a few others) to choose a function
>which clashes with a console command : write. :-( :-) Any idea what to do
>in such cases ?

If you don't already know what manual section it is in, use
man -k to find all the relevent pages:

$ man -k fprintf

asprintf (3) - print to allocated string
dprintf (3) - print to a file descriptor
format (n) - Format a string in the style of sprintf
fprintf (3) - formatted output conversion
fprintf (3p) - print formatted output
fwprintf (3) - formatted wide-character output conve

Then use the section number:

$ man 3 fprintf

Section 1 is commands, 2 is system calls, 3 is library functions,
4 is device special files, etc.

1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]

[Jerry Stuckle]

On 8/30/2016 8:01 AM, R.Wieser wrote:
> Öö Tiib,

>
>> In former 'server' is variable that contains all data of structure
>> 'hostent'. To get address to it you need to type '&server'.
>
> Agreed.
>
>> In latter 'server' is pointer variable that can contain address
>> of structure 'hostent'.
>
> Again, agreed.
>
>> When it is pointing at actual 'hostent' then you may dereference it.
>
> YES. How do I do that ?
>
>> For dereferencing you need to type '*server' (or 'server->' if you
>> want access particular member of it).
>
> In my first post I indicated I used the latter using the first member of the
> structure, but I consider that to be a hack. I also indicated that I tried
> "(*server)", and that it gave me a compile-time error.
>
> Any other ideas ?
>
> Regards,
> Rudy Wieser
>
>

Look at his update again. He isn't using the address of the first
member - he isn't referencing any member of the struct. You can take
the address of it with & and dereference it with *. For instance:

struct hostent server; // the actual structure

struct hostent* pserver = &server; // A pointer to the structure

At this level, it's really no different than other variables, i.e.

int i; // an int
int *ip = &i; // A pointer to an int

And you can use them just like other pointers, i.e.

void f(struct hostent * ps);

f(&server); // Use the address of the structure
f(pserver); // Use a pointer to the structure

Does this help?

And I agree with the others - you really need to find a good basic book
on C++ (or here, even C). It will help you much more than trying to
fumble your way through.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Scott Lurndal]

"R.Wieser" <add...@not.available> writes:
>Funny:
>
>> In short: How do I dereference that "server" variable so
>> the function receives a pointer to the structure ?
>
>Odd: several replies, but none that actually told me how its done. Is it
>some deep-dark secret that only masters of the trade are allowed to know ?

Pointers are the most basic of concepts in C, and C++.

>
>And for some of you guys here: don't try to second-guess what I'm after.
>I'm in the habit of trying to ask my questions as exact as I can, needing it
>to have *it* answered. (that does not mean that I do not appreciate further
>hints in the same direction though!)
>
>Do I really need to waste hours googeling hoping I will stumble over the
>(most likely rather simple) answer ?

If you don't craft your question carefully, you won't get an useful answer.

The question, as originally posted, didn't really make sense in the context
of C or C++ programming. Casting your 'server' variable to an unsigned
char pointer is incorrect in either language.

[Chris Vine]

On Tue, 30 Aug 2016 11:33:23 +0200
"R.Wieser" <add...@not.available> wrote:
> Funny:
>
> > In short: How do I dereference that "server" variable so
> > the function receives a pointer to the structure ?
>
> Odd: several replies, but none that actually told me how its done.
> Is it some deep-dark secret that only masters of the trade are
> allowed to know ?

You have been told the answer (see the response of 29 August at
19:16:59 UTC). 'server', as in:

struct hostent *server;

is declared as a pointer and can be passed as a pointer. It _is_ a
pointer. You only need to dereference it if you want to obtain the
structure's members. There is no secret here. It is the most basic C.

You really do need to get a decent textbook on the C language. (Or
the C++ language if that is what you want to learn.)

> And for some of you guys here: don't try to second-guess what I'm
> after. I'm in the habit of trying to ask my questions as exact as I
> can, needing it to have *it* answered. (that does not mean that I do
> not appreciate further hints in the same direction though!)
>
> Do I really need to waste hours googeling hoping I will stumble over
> the (most likely rather simple) answer ?

Don't google. When learning a language get a textbook to learn the
basics.

Part of the confusion may be that when you said you were "a novice in
regard to using C++ (GCC) *and* using linux" people thought that it was
the specific gcc and linux issues you were unfamiliar with, not the
basics of C and C++ itself. You gave the impression that you had
done some windows programming.

The other difficulty is that you have an attitude problem which is
considerably larger than your state of knowledge; this is going to get
you into trouble, both in your code and in your interactions on this
news group.

Chris

[R.Wieser]

Paavo,

> I express my opinions, you express yours.

Nope. You use your "opinions" as an excuse not to post anything in regard
to an answer to the problem as I posted it. "Go away. Go learn for
yourself. If you do not you will never discover what its all about".
Really ? *Thats* how you help people ? In that case, I wonder what you
would do if you would *not* be willing to help ...

> Yes, that was concrete enough, thank you.

Good.

> 2) foobar(reinterpret_cast<unsigned char*>(server2));

Why are you writing it like that, when my posted code uses a different
make-up (syntax?) *AND* I've indicated I'm a beginner ?

But, lets assume you ment:

foobar( (unsigned char*) server2 );

Than you're mistaken (adding brackets around "server2" does not help
either).

Oh, it *compiles* well enough, but the argument in the foobar function will
than be pointing at the the value stored into that "server2" variable, not
the data in the "hostent" structure.

Also explain to me how currently

foobar( (unsigned char*) server2-> h_addr );

works for me, but I than can just remove the "->h_addr" part and get the
same (compile-time!) result ...

> A proper code sample is preferably a complete source
> file including all the #includes as well as int main().

Forget it. The only thing it would lead to is that you (and others like
you) would making suggestions about *everything* in there, but not the
problem. Heck, even now you have troubles with concentrating yourself on
the problem.

Over the years I've posted enough questions (few, but enough) to have
encountered the above many times. Shucks, why do you think I named the
function "foobar" instead of its actual name ? Thats because what it, and
the rest of the code does has got *nothing* to do with the *compile-time*
problem.

But, if you are amadant about only being able to glean the problem (and its
answer) from such full code I could waste some time to gut everything
irrelevant outof my current code (while ofcourse still causing the
compile-time error mind you). Apart from the includes for the standard IO,
the structure, the gethostbyname function, a minimal "main" declaration and
an as minimal "foobar" one (being fully gutted) you would see nothing more
than what I already posted.

By the way: have you already tried to put those three lines of code I posted
in my initial message into some test program and seen if you could get it to
compile ? Why not ? I think it would probably have been quite the
eye-opener for you.

Regards,
Rudy Wieser


-- Origional message:
Paavo Helde <myfir...@osa.pri.ee> schreef in berichtnieuws

M6idnSfk5aQA6VjK...@giganews.com...

[Paavo Helde]

On 30.08.2016 16:14, R.Wieser wrote:
> Paavo,
>
>> I express my opinions, you express yours.
>
> Nope. You use your "opinions" as an excuse not to post anything in regard
> to an answer to the problem as I posted it. "Go away. Go learn for
> yourself. If you do not you will never discover what its all about".
> Really ? *Thats* how you help people ? In that case, I wonder what you
> would do if you would *not* be willing to help ...

(plonk)

[R.Wieser]

Scott,

> The man pages are your friend.

:-) I was, just as under Windows, trying to go the opposite way -- from
function to documentation -- (Windows does not really have any decent "man"
page support), but yes, "man" seems to work rather well under Linux.

And thanks for the info-selection methods too.

Regards,
Rudy Wieser


-- Origional mesage:
Scott Lurndal <sc...@slp53.sl.home> schreef in berichtnieuws
Gafxz.1214$LR....@fx17.iad...

[R.Wieser]

Scott,

> $ nm -D /usr/lib64/libzip.so.2 | grep " T " |more

Looks like its very usable, thanks. :-)

Regards,
Rudy Wieser


-- Origional message:

Scott Lurndal <sc...@slp53.sl.home> schreef in berichtnieuws

s5fxz.1213$LR....@fx17.iad...

[R.Wieser]

Scott,

> Then use the section number:
>
> $ man 3 fprintf
>
> Section 1 is commands, 2 is system calls, 3 is library functions,
> 4 is device special files, etc.

Thanks again. Thats rather usefull (to make an understatement).

Regards,
Rudy Wieser


-- Origional message:

Scott Lurndal <sc...@slp53.sl.home> schreef in berichtnieuws

Cdfxz.1215$LR....@fx17.iad...

[Ben Bacarisse]

"R.Wieser" <add...@not.available> writes:

> Richard,
>
>> Here 'server' is a variable holding the address of a
>> 'hostent' structure. server *is* the address.
>
> I'm sorry, but I disagree with you. Just consider the difference between
>
> struct hostent server;
>
> and
>
> struct hostent *server;
>
> I regard your above statement true for the first, not the latter.

No, the first is a variable (C and C++ call it an object) that holds the
structure. The second is an object that holds the address of a struct.

> As far as
> I can tell for the latter "server" is the addres of the variable which holds
> the address to the "hostent" structure (hence the need for
> dereferencing).

If you just want the address of the hostent strict you just write server
because that variable already holds the address you want. But the code
you showed suggested a different intention:

foobar( (unsigned char*) server->h_addr, ... )

This suggest you might want to pass the address of the first member of
the list of discovered host addresses: h_addr is a legacy macro that
expands to h_addr_list[0]. If that's what you want, then you've got the
right code. You don't even need the cast if your function can take a
char * argument.

But, to repeat, if you just want the address of the whole hostent
struct, you already have it in server.

<snip>
--
Ben.

[R.Wieser]

Jerry,

> Does this help?

I'm sorry, no. I read the same, and thought I understood.

You seem to say that what he wrote works, while the compiler on my machine
still throws an compile-time error.

I can see that "server->h_addr" and "*server" *should* return the same
address. The problem is that I can't get the latter to be accepted (and, as
I'm a beginner, assumed I did something wrong), and I have *no* idea why.

Do you ?

Regards,
Rudy Wieser


Jerry Stuckle <jstu...@attglobal.net> schreef in berichtnieuws
nq3v9u$sm2$1...@jstuckle.eternal-september.org...

> On 8/30/2016 8:01 AM, R.Wieser wrote:

> > 嘱 Tiib,

[R.Wieser]

Scott,

> >Odd: several replies, but none that actually told me how its done. Is
it
> >some deep-dark secret that only masters of the trade are allowed to know
?
>
> Pointers are the most basic of concepts in C, and C++.

I should have added the "</sarcasm>" tag, but felt like I would be overdoing
it.

> Casting your 'server' variable to an unsigned char pointer
> is incorrect in either language.

Seems to be untrue. The compiler accepts "(unsigned char*) server" without
even a warning. Using that result does not seem to cause any problems
either.

Regards,
Rudy Wieser


-- Origional message:
Scott Lurndal <sc...@slp53.sl.home> schreef in berichtnieuws

Fgfxz.1216$LR....@fx17.iad...

[Reinhardt Behm]

R.Wieser wrote:

> Jerry,
>
>> Does this help?
>
> I'm sorry, no. I read the same, and thought I understood.
>
> You seem to say that what he wrote works, while the compiler on my machine
> still throws an compile-time error.
>

> I can see that "server->h_addr" and "*server" should return the same

> address. The problem is that I can't get the latter to be accepted (and,

> as I'm a beginner, assumed I did something wrong), and I have no idea why.
>

Since we do not know what you function foo accepts as its parameter, we can
not really explain it. From what you write it seems it expect a pointer to a
char (char*). That would explain that the first form "server->h_addr" is
accepted by the compiler. But neither "*server" not "server" is a char
pointer. "*server" is a "struct hostent", assuming it has been set correctly
and "server" is a pointer to struct hostent.

To me it looks as if you do not know that in C (or C++) a pointer is not
just an address. It also has the property to point to a certain type.

So if your function foo expects a char pointer, meaning it is defined as
void foo(char *ptr);
You have to call it with a char pointer, not with a pointer to struct
anything.
This is true even if your variable "server" contains the address (as a bit
pattern) of the first byte of some struct hostent which by chance is also
the address of char or char array and the address of this char (server-
>h_addr) has the same bit pattern it is syntactically some thing different.
That willlead to your compiler complaining.

One tip: If you think it is to much effort to show something more of your
code,then just show us at least the definition of such functions because it
not irrelevant. Or show us the compiler message.

--
Reinhardt

[Scott Lurndal]

"R.Wieser" <add...@not.available> writes:
>Scott,
>
>> >Odd: several replies, but none that actually told me how its done. Is
>it
>> >some deep-dark secret that only masters of the trade are allowed to know
>?
>>
>> Pointers are the most basic of concepts in C, and C++.
>
>I should have added the "</sarcasm>" tag, but felt like I would be overdoing
>it.
>
>> Casting your 'server' variable to an unsigned char pointer
>> is incorrect in either language.
>
>Seems to be untrue. The compiler accepts "(unsigned char*) server" without
>even a warning. Using that result does not seem to cause any problems
>either.

Syntactically, perhaps. Semantically, it's catch as catch can - in this
case yours works by luck because the first field in the structure is
an array of characters.

If you have to cast something explicitly, you're generally doing the wrong thing.

struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses */
}

struct hostent server;

void do_something_with_hostname(char *hostname);


do_something_with_hostname(server->h_name);


or

void do_something_with_hostent(struct hostent *); /* C definition */
void do_something_with_hostent(hostent *); /* C++ definition */


Note that the first field of struct hostent is a pointer to a
signed character. For historical reasons all strings in C and
C++ are considered to be arrays of signed characters, and the
compilers will complain if you attempt to pass server->h_name as
the argument of a function that takes 'unsigned char *' as an
argument.

From the GCC man page (only applies to the C compiler, not the C++ compiler)

Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on
the signedness of an object. But many programs have been written to use plain "char" and expect it
to be signed, or expect it to be unsigned, depending on the machines they were written for. This
option, and its inverse, let you make such a program work with the opposite default.

[Jerry Stuckle]

On 8/30/2016 9:43 AM, R.Wieser wrote:
> Jerry,
>
>> Does this help?
>
> I'm sorry, no. I read the same, and thought I understood.
>
> You seem to say that what he wrote works, while the compiler on my machine
> still throws an compile-time error.
>
> I can see that "server->h_addr" and "*server" *should* return the same
> address. The problem is that I can't get the latter to be accepted (and, as
> I'm a beginner, assumed I did something wrong), and I have *no* idea why.
>

Server->h_addr is a member of the structure. If it is an int, the code
will return an int. If it is a double, the code will return a double.

If it is an array, it will return the address of the first element in
the struct. This will be the same as the address of the struct - but
*only if this is the first element in the struct*. Should the struct
change at a later time, this will not be true (and will probably cause a
very difficult to find bug).

> Do you ?
>
> Regards,
> Rudy Wieser
>

No, because you haven't shown enough code. If the function takes a type
server*, then it should work as I explained. If it takes something
else, you shouldn't be passing a server* to it.

Function prototypes have a purpose - to indicate what type of parameters
the function accepts (and what it returns). Don't try to pass a B when
it expects an A. It doesn't work.

[Richard]

[Please do not mail me a copy of your followup]

"R.Wieser" <add...@not.available> spake the secret code
<57c54e78$0$937$e4fe...@news.xs4all.nl> thusly:

>Richard,
>
>> Here 'server' is a variable holding the address of a
>> 'hostent' structure. server *is* the address.
>

>I'm sorry, but I disagree with you. [...]

Then you don't yet understand the fundamentals of the language. Take
some on-line courses on C or C++ and learn the fundamentals of
pointer types first.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

"R.Wieser" <add...@not.available> spake the secret code

<57c5521f$0$872$e4fe...@news.xs4all.nl> thusly:

>And for some of you guys here: don't try to second-guess what I'm after.
>I'm in the habit of trying to ask my questions as exact as I can, needing it
>to have *it* answered. (that does not mean that I do not appreciate further
>hints in the same direction though!)

Please read "How to Ask Questions the Smart Way":
<http://www.catb.org/esr/faqs/smart-questions.html>

Your approach is directly at odds with getting the best way of
getting help from a programmer oriented newsgroup.

[jacobnavia]

Le 30/08/2016 à 08:05, Gareth Owen a écrit :
> jacobnavia <ja...@jacob.remcomp.fr> writes:

> Actually, none of Jacob's "answers" are the most likely - what he knows
> about linux couldn't fill a hat. Doesn't stop him having opinions, of
> course.
>

I could say the same thing about you.

You do not know anything about me. I have been using linux since at
least 1995 or so.

But keep your opinion.

[Manfred]

On 8/30/2016 11:33 AM, R.Wieser wrote:
> Funny:
>
>> In short: How do I dereference that "server" variable so
>> the function receives a pointer to the structure ?
>

> Odd: several replies, but none that actually told me how its done. Is it
> some deep-dark secret that only masters of the trade are allowed to know ?

You had the correct answer, but you appeared to be too much busy
attacking the guy who gave you such correct answer in order to get it.

>
> And for some of you guys here: don't try to second-guess what I'm after.
> I'm in the habit of trying to ask my questions as exact as I can, needing it
> to have *it* answered. (that does not mean that I do not appreciate further
> hints in the same direction though!)
>

> Do I really need to waste hours googeling hoping I will stumble over the
> (most likely rather simple) answer ?

You can't hope to learn C and/or C++ by googleing around. Get a good
textbook instead.
Besides, many have already already given you the information you asked for.
But it looks as if your attitude got you convinced that they were all wrong.

Regards,
Manfred

[R.Wieser]

Jerry,

> No, because you haven't shown enough code. If the
> function takes a type server*, then it should work as
> I explained

Ehrmm .... In my first post in this thread I did show how I call the foobar
function, indicating I'm attempting to coerce the provided variable into an
unsigned char* before passing it on as the functions argument.

If the argument defined in the foobar function itself would be of a
different type I would (as far as I know) get a compile-time error because
of a mismatch. Hence, the function must look like this:

{undefined} foobar(unsigned char* argument , ....)

And it does. :-)

> Don't try to pass a B when it expects an A. It doesn't work.

Agreed.

Regards,
Rudy Wieser


-- Origional message:

Jerry Stuckle <jstu...@attglobal.net> schreef in berichtnieuws

nq472u$mg3$1...@jstuckle.eternal-september.org...

[R.Wieser]

Chris,

> You have been told the answer (see the response of 29 August at
> 19:16:59 UTC). 'server', as in:
>
> struct hostent *server;
>
> is declared as a pointer and can be passed as a pointer.

And I've told this group several times that IT DOESN'T WORK.

You can keep giving me the same "this should work" as many times as you
like, but my compiler is rather uninpressed by this against-the-facts
insistance, laughs about it a bit and just keeps throwing the compile-time
error. :-\

I do wish you guys could convince him otherwise though. :-)

> is declared as a pointer and can be passed as a pointer. It
> _is_ a pointer. You only need to dereference it if you want
> to obtain the structure's members. There is no secret here.
> It is the most basic C.

Absolutily.

So, why don't you tell me why "server->h_addr" works, but "*server" won't ?

> Part of the confusion may be that when you said you were
> "a novice in regard to using C++ (GCC) *and* using linux"
> people thought that it was the specific gcc and linux issues
> you were unfamiliar with, not the basics of C and C++ itself.

Irrelevant. I think the question is clear enough. Regardless of if its a
high-level problem, or one as basic as this one. Heck, as its a problem
that has to do with "the basics of C and C++ itself" *everyone* here (above
the novice level) should know what to do about it, don't you think ?

> You gave the impression that you had done some
> windows programming.

I have. I didn't mention which language though. :-)

I mentioned to indicate that I'm no stranger to the logic of programming, or
its syntax. That does not mean I know everything, or cannot run into
stupid "you have to do it exactly *this* way" problems when encountering a
new language.

> The other difficulty is that you have an attitude problem
> which is considerably larger than your state of knowledge;

You think *I* have an attitude problem, when being confronted with a slew of
people who do not read (advising me to try stuff I wrote already I did), and
do not take "No, it doesn't work" for an answer ? You must be joking. :-|

> this [attitude] is going to get you into trouble, both in your code

That "in your code" I do not quite understand. My code has no problem with
who I am, what I look like or how many keyboards I go thru in an average
session. :-)

> and in your interactions on this news group.

True. But I don't mind to get rid of people who only know one answer, and
keep repeating that same answer over-and-over again because they simply
refuse to accept that it doesn't work. *That* attitude is simply
infuriating.

... and I guess that my getting "rather annoyed" shows in my answers. :-)
:-\


But please do explain why "server->h_addr" works, but "*server" not. I
could really use it. If it simply doesn't (for whatever reason) I will be
content too (though you stand a chance that I will say "Ha! Told you so!"
to several of this threads contributors. Sorry.)

Regards,
Rudy Wieser

P.s.
I think I gave enough code in my first post to reproduce the problem.
Currently I have not heard of anyone trying and either having a pro or con
experience. Odd.


-- Origional message:
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> schreef in berichtnieuws
20160830135...@dell.homenet...

[R.Wieser]

Scott,

> Syntactically, perhaps. Semantically, it's catch as catch
> can - in this case yours works by luck because the first
> field in the structure is an array of characters.

Are you sure about that ?

Wait, two things:

One: if what you say is true than I should not need to call the function
including coercing the "server" variable with "(unsigned char*)"

Two: the percieved type of a structure is the same as that of its first
field ?

... testing ...

Nope on both. The compiler complains about "hostent*" not being compatible
to "unsigned char*". And that sound logical to me.

> If you have to cast something explicitly, you're generally
> doing the wrong thing.

Agreed. In this case though its intentional.

> struct hostent {
[snip]

Thanks for the examples.

Well, thats something else: The "foobar" routine is not only for that one
structure, or for structures only for that matter. Comparable to the
"write" function I guess. You can write *any* data with it, as long as you
coerce the data's type into the one "write"'s argument expects.

And yes, If I would have wanted to use a fields data as its stored in there
it stands to reason to receive that field in an argument of the exact same
type (ignoring signed/unsigned differences here).

Regards,
Rudy Wieser


-- Origional message:
Scott Lurndal <sc...@slp53.sl.home> schreef in berichtnieuws

s1hxz.19182$IH3....@fx40.iad...

[R.Wieser]

Richard,

> Then you don't yet understand the fundamentals of the language.

It could also be that I have a better understanding of what goes on below
than you do.

You see, you do not seem to understand the difference between a structures
address, and a variable *used as* a pointer *to hold* some other variables
address.

When you say "server *is* the address" you are right. But it is the address
of the "server" variable itself, not whatever it addres is stored as its
contents.

Granted, the language itself makes it easy for you to just forget such
fundamental things about it, and just throw something at it to get it
silently dereferenced to get at the actual structure.

Heck, why do you think both "." and "->" exist to access a strucures fields
?

Regards,
Rudy Wieser


-- Origional message:

Richard <legaliz...@mail.xmission.com> schreef in berichtnieuws
nq4cdc$c2b$1...@news.xmission.com...

[R.Wieser]

Manfred,

> You had the correct answer, but you appeared to be too
> much busy attacking the guy who gave you such correct
> answer in order to get it.

If the answer was correct, why didn't it work for me ?

And pardon me, but I think I have mentioned that at least the first few
times. After that ? Yeah, how many times do you think I should be
repeating the same answer (to the same suggestions) ?

> Besides, many have already already given you the information
> you asked for. But it looks as if your attitude got you convinced
> that they were all wrong.

You mean you didn't notice that I've mentioned a number of times I got a
compile-time error when I tried the suggestions ? Are you really trying
to shoot the *messenger* here ?

I tried *everything* that was suggested. I even retried a number of things
I had already done, because maybe I did something wrong the last time (on my
own) but *this* time (doing it exactly as suggested) it would work.

But there is one thing I simply cannot stand: And that is when I say that
something doesn't work the other party keeps insisting that it does <full
stop>.

Next to that, at the same time not getting any suggestions to what I could
try to find the problem (in my understanding or in the code) is not funny
either (And no, all that was needed for that was present in the first
message).

Regards,
Rudy Wieser


Manfred <non...@invalid.add> schreef in berichtnieuws
nq4i5q$ofh$1...@gioia.aioe.org...

[R.Wieser]

Reinhardt,

> Since we do not know what you function foo accepts as its
> parameter, we can not really explain it. From what you write
> it seems it expect a pointer to a char (char*).

Huh? In the first line you tell me you do not know, and in the second you
tell me you do .... :-)

> But neither "*server" not "server" is a char pointer.

True. That is why I needed to coerce either of them into it.

> "*server" is a "struct hostent", assuming it has been set
> correctly and "server" is a pointer to struct hostent.

With all the "not working" going on I'm not sure if I understand that. I
*thought* I did, but not anymore.

> To me it looks as if you do not know that in C (or C++)
> a pointer is not just an address. It also has the property
> to point to a certain type.

You mean why all that type-casting is neccesary ? Yes, I'm aware of that
(how could I not, seeing how I'm struggeling with it :-) )

> So if your function foo expects a char pointer, meaning it is
> defined as void foo(char *ptr);
> You have to call it with a char pointer, not with a pointer to
> struct anything.

Thats why I am trying my damn best to coerce that struct pointer into an
unsigned char pointer. :-)

> ... it is syntactically some thing different

I'm afraid that it will take some time before my brain will be at ease with
that.

> One tip: If you think it is to much effort to show something
> more of your code,

Its not about effort. I could just grab the whole sourcefile and dump in
in the next message. I consider that to be offensive -- as if you do not
even take the time to figure out which part is actually malfunctioning, and
leave it upto the reader to do all the work.

> then just show us at least the definition of such functions
> because it not irrelevant.

I thought I did so in my first message in this thread, but I did not do so
explicitily. I however posted calling the function itself:

foobar( (unsigned char*) server->h_addr, ... )

As far as I'm aware you cannot call a function with an argument of a type
different than specified in the function itself. In other words, the
definition of the function is this:

void foobar(unsigned char* argument , .....)

> Or show us the compiler message.

Although I did not copy-paste, I mentioned the compile-time error messages
for both "*server" as well as "server->" in an earlier message.

I think I did my best to give everything I was/am aware of being able to
give.

Regards,
Rudy Wieser


-- Origional message:

Reinhardt Behm <rb...@hushmail.com> schreef in berichtnieuws
nq43jf$ape$1...@dont-email.me...

[R.Wieser]

For all people that tried to help me find a solution to that "server"
variable problem, it turns out to be rather simple, and due to a mistake
made by me.

Yes!, I'm one of those people that does not run away when he has made one,
and comes out openly for it. If you can't handle that, tough shit.


But don't think you're without blame here !.


From my initial message:

> The only way I was able to do that was to refer to the first
> (and in this case only) field in that structure:

>
> foobar( (unsigned char*) server->h_addr, ... )

*Both* the "first" and "only" descriptions where wrong. Next to that
"h_addr" isn't even a field in that hostent record, but in a ipv4/ipv6 table
that the hostent record holds a pointer to, and *noone* here noticed any of
those three mistakes. Doesn't anybody actually *read* a question before
replying to it ? :-( :-)

(I was actually thinking of another structure, just holding an ipv4 or ipv6
address)


In the end it turned out that "foobar( (unsigned int*) server , ...)" (which
I had tried long before posting my problem here) actually did give me the
address of the hostent structure, but as "server->h_addr" and the above
where not looking at the same spot (remember, I thought that h_addr was the
first-and-only field in the record) I assumed I was looking at the pointer
variables data (the addres to the structure) itself (where "server->h_addr"
showed me, by accident, the expected IPv4 address)

I do not know anymore who all suggested using just "server", you guys where
right all along. Heck, even *I* was right, long before you guys :-)

For all who suggested "*server" or "server->". Sorry, no go.


My apologies for not having played a subdued novice all along, but heck, do
you guys fail at reading and trying to figure out what could have gone wrong
...

And no, that does not take anything away from the mistakes I made myself.
The initial wrong assumption, and having waited so long before
double-checking if that "h_addr" field was where I thought it would be.

Regards,
Rudy Wieser


-- Origional message:

R.Wieser <add...@not.available> schreef in berichtnieuws
57c4895a$0$871$e4fe...@news.xs4all.nl...
> Hello all,
>
> Fair warning: I'm a novice in regard to using C++ (GCC) *and* using linux
> (lubuntu to be exact). If this is not the newsgroup to be asking
questions
> like the below than please advice which newsgroup(s) to use instead.
>
> - - - - - -
> First problem, C++ related:
>
> I need to transfer the address of a structure to a function, and have only
> be able to find a hackish solution for it. The problem is that the
variable
> I've got is actually a pointer, and I have no idea how to dereference it.
>
> The variable declaration and initialisation in case:
>
> struct hostent *server;
> server = gethostbyname(argv[1]);
>
> Now I want to transfer the address stored in the "server" variable to a
> function. The only way I was able to do that was to refer to the first
(and
> in this case only) field in that structure:

>
> foobar( (unsigned char*) server->h_addr, ... )
>

> I read somewhere that I could use (*server) , but trying it ( (unsigned
> char*) (*server) ) gave a compile-time error.

>
> In short: How do I dereference that "server" variable so the function
> receives a pointer to the structure ?
>

> - - - - - -
> Second problem, Linux related:

>
> As someone wo has spend quite some time on Windows I'm rather accustomed
> being able to pick a DLL and look inside it to see which functions it
> exposes that I can use (yeah, I still have to generate a library from it
and
> find the function declarations, but thats not the point).
>

> I have no idea how to do the same under Linux (and/or how to convert the
> found functions (system calls ?) to something I can use in C++ ).
>
> To be honest, I have no idea if the above is even feasible for C++ (GCC)
> under linux.
>
> I did find an example using "nm", but that only showed the contents of the
> .o (library) file, and only if the info was not stripped.
>
> I also tried that on the full /usr directory, but could not even find
> "fprint" (found buf_fprint" and "str_fprint" though).
>
>
> And now I'm on a roll asking questions, one thing I did not expect was to
> find multiple (sometimes over 10) same-named header files , most often of
> different sizes. Whats the idea behind that, and how should I know which
> one of those to include ?
>
> Regards,
> Rudy Wieser
>
>
>

[Vir Campestris]

On 30/08/2016 09:09, R.Wieser wrote:
> I'm sorry, but I disagree with you. Just consider the difference between
>
> struct hostent server;
>
> and
>
> struct hostent *server;
>

> I regard your above statement true for the first, not the latter. As far as

> I can tell for the latter "server" is the addres of the variable which holds
> the address to the "hostent" structure (hence the need for dereferencing).
>

Can you read assembler?

foo(struct hostent s) {}
bar(struct hostent *s {}

struct hostent server;
foo(server); /* Disassembly will show it copying the */
/* whole of server onto the stack for the call */

struct hostent *pserver = &server;

bar(pserver); /* Disassembly will show a single push of */
/* a 32 or 64 bit address onto the stack */

pserver is on any architecture you are likely to come across a single
register containing the address of server.

This is basic C. Talk to your teachers.

Andy

[Jerry Stuckle]

On 8/30/2016 1:32 PM, R.Wieser wrote:
> Jerry,
>
>> No, because you haven't shown enough code. If the
>> function takes a type server*, then it should work as
>> I explained
>
> Ehrmm .... In my first post in this thread I did show how I call the foobar
> function, indicating I'm attempting to coerce the provided variable into an
> unsigned char* before passing it on as the functions argument.
>

Yes, but you only posted partial code, and even then you changed the
types, function names, etc. Are we supposed to read your mind as to
what the code *really is*? I don't think so.

But you have a problem because you're not passing an unsigned char * to
the function; rather you're passing a hostent*. The two are *not the
same thing*.

> If the argument defined in the foobar function itself would be of a
> different type I would (as far as I know) get a compile-time error because
> of a mismatch. Hence, the function must look like this:
>
> {undefined} foobar(unsigned char* argument , ....)
>
> And it does. :-)
>
>> Don't try to pass a B when it expects an A. It doesn't work.
>
> Agreed.
>

Then don't do it. Pass the correct parameter.

[Jerry Stuckle]

On 8/30/2016 11:01 AM, R.Wieser wrote:
> Chris,
>
>> You have been told the answer (see the response of 29 August at
>> 19:16:59 UTC). 'server', as in:
>>
>> struct hostent *server;
>>
>> is declared as a pointer and can be passed as a pointer.
>
> And I've told this group several times that IT DOESN'T WORK.
>

It WORK'S WHEN YOU DO IT RIGHT.

Rather than argue with everyone, post the *REAL CODE* that fails. Not
some partial code that we're supposed to use to guess what you really need.

And please - GET A GOOD C++ BOOK. You can't learn by googling the internet.

[Jerry Stuckle]

On 8/30/2016 3:38 PM, R.Wieser wrote:
> For all people that tried to help me find a solution to that "server"
> variable problem, it turns out to be rather simple, and due to a mistake
> made by me.
>
> Yes!, I'm one of those people that does not run away when he has made one,
> and comes out openly for it. If you can't handle that, tough shit.
>
>
> But don't think you're without blame here !.
>
>
> From my initial message:
>
>> The only way I was able to do that was to refer to the first
>> (and in this case only) field in that structure:
>>
>> foobar( (unsigned char*) server->h_addr, ... )
>
> *Both* the "first" and "only" descriptions where wrong. Next to that
> "h_addr" isn't even a field in that hostent record, but in a ipv4/ipv6 table
> that the hostent record holds a pointer to, and *noone* here noticed any of
> those three mistakes. Doesn't anybody actually *read* a question before
> replying to it ? :-( :-)

Yes, we READ it. But you posted INCOMPLETE and INCORRECT information.
If you would have posted COMPLETE and CORRECT information in the first
place, we could have helped you better.

And you wonder why people want compileable code... This is a perfect
example. Had you done that in the first place, you would have had the
correct answer immediately.

[Reinhardt Behm]

R.Wieser wrote:

> Reinhardt,
>
>> Since we do not know what you function foo accepts as its
>> parameter, we can not really explain it. From what you write
>> it seems it expect a pointer to a char (char*).
>
> Huh? In the first line you tell me you do not know, and in the second you
> tell me you do .... :-)

Problem of comprehensive reading?
Since do never showed any prototype for your function, we do not know and I
did not tell you I know, but only what on could guess from your incomplete
information.

At least your self confidence does not seem to be lacking.

--
Reinhardt

[BartC]

On 30/08/2016 19:34, R.Wieser wrote:

>> Then you don't yet understand the fundamentals of the language.
>
> It could also be that I have a better understanding of what goes on below
> than you do.
>
> You see, you do not seem to understand the difference between a structures
> address, and a variable *used as* a pointer *to hold* some other variables
> address.

Suppose you have a struct definition 'hostent':

If S is a struct variable (as in struct hostent S), then &S is the
struct's address. A variable to hold it might be 'struct hostent *P'.

> When you say "server *is* the address" you are right. But it is the address
> of the "server" variable itself, not whatever it addres is stored as its
> contents.

In the case of P above, P is the address of a hostend struct (or will be
when initialised). The address of P will be &P (of type struct hostend
**), but you probably don't want that.

> Granted, the language itself makes it easy for you to just forget such
> fundamental things about it, and just throw something at it to get it
> silently dereferenced to get at the actual structure.
>
> Heck, why do you think both "." and "->" exist to access a strucures fields
> ?

"P -> m" is just a neater way of writing of (*P).m.

Here, P is a pointer to a struct. On the other hand, S.m means that S is
a struct, not a pointer.

In your OP, you didn't give the declaration of the function that you
want to pass your struct pointer to (nor of the struct itself), so it's
difficult to know exactly how it ought to be passed. (Maybe it's been
mentioned in the rest of the thread; I haven't read all of it.)


--
Bartc

[BartC]

On 29/08/2016 21:04, Vir Campestris wrote:

> On 29/08/2016 20:16, R.Wieser wrote:
>> As someone wo has spend quite some time on Windows I'm rather accustomed
>> being able to pick a DLL and look inside it to see which functions it
>> exposes that I can use (yeah, I still have to generate a library from
>> it and

(With some compilers you can just give them the .dll files; no library
needed.)

>> find the function declarations, but thats not the point).
>>
>> I have no idea how to do the same under Linux (and/or how to convert the
>> found functions (system calls ?) to something I can use in C++ ).
>

> As someone who started using Linux not many years ago after many years
> of other systems, which included a _lot_ of Windows - I've almost never
> had to do that on Windows. If someone wants you to use their library
> they'll provide a .h file, and you include that. Then you link against
> the library.

You've been lucky then in using just the right language that the authors
of the library intended and being able to use a .h file simply by
including it.

If you want to use these libraries from outside of C or C++ then it's
much harder and you will often need to look inside dll files. Although
that won't tell you the function signatures (not for C-originated
functions), and some extra information is needed.

Sometimes that means delving inside .h files and needing to understand
them (just about practical for C; I don't even bother if C++ is involved).

--
Bartc

[Richard]

[Please do not mail me a copy of your followup]

BartC <b...@freeuk.com> spake the secret code
<nq6amk$2ku$1...@dont-email.me> thusly:

>On 29/08/2016 21:04, Vir Campestris wrote:
>> On 29/08/2016 20:16, R.Wieser wrote:
>>> As someone wo has spend quite some time on Windows I'm rather accustomed
>>> being able to pick a DLL and look inside it to see which functions it
>>> exposes that I can use (yeah, I still have to generate a library from
>>> it and
>
>(With some compilers you can just give them the .dll files; no library
>needed.)

Which ones?

[BartC]

On 31/08/2016 21:33, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> BartC <b...@freeuk.com> spake the secret code
> <nq6amk$2ku$1...@dont-email.me> thusly:
>
>> On 29/08/2016 21:04, Vir Campestris wrote:
>>> On 29/08/2016 20:16, R.Wieser wrote:
>>>> As someone wo has spend quite some time on Windows I'm rather accustomed
>>>> being able to pick a DLL and look inside it to see which functions it
>>>> exposes that I can use (yeah, I still have to generate a library from
>>>> it and
>>
>> (With some compilers you can just give them the .dll files; no library
>> needed.)
>
> Which ones?

I think gcc, Tiny C and g++.

--
Bartc

[R.Wieser]

Andy,

> Can you read assembler?

I think so.

> bar(pserver); /* Disassembly will show a single push of */
> /* a 32 or 64 bit address onto the stack */

You're cheating here. :-)

The devil is in the details.

PUSH pserver

is quite a bit different than

PUSH [pserver]

> pserver is on any architecture you are likely to come across
>a single register containing the address of server.

Correct.

Though under Assembly "pserver" is nothing more than a design-time label,
being converted at compile-time to a fixed address pointing at a bit of
memory where its 'contents' are stored. Contents which than point to the
actual "server" record.

Now do you understand my request for dereferencing ?

This is basic Assembly. Talk to your teachers. :-)

Regards,
Rudy Wieser


-- Origional message:

Vir Campestris <vir.cam...@invalid.invalid> schreef in berichtnieuws
KpCdnaiHZ8iocljK...@brightview.co.uk...

[BartC]

On 01/09/2016 10:38, R.Wieser wrote:
> Andy,
>
>> Can you read assembler?
>
> I think so.
>
>> bar(pserver); /* Disassembly will show a single push of */
>> /* a 32 or 64 bit address onto the stack */
>
> You're cheating here. :-)
>
> The devil is in the details.
>
> PUSH pserver
>
> is quite a bit different than
>
> PUSH [pserver]
>
>> pserver is on any architecture you are likely to come across
>> a single register containing the address of server.
>
> Correct.
>
> Though under Assembly "pserver" is nothing more than a design-time label,
> being converted at compile-time to a fixed address pointing at a bit of
> memory where its 'contents' are stored. Contents which than point to the
> actual "server" record.

The definition for pserver was as a pointer variable initialised to the
address of a struct (&server).

On x86, a push of that variable would be of the form PUSH [pserver]. If
register-resident, it would be PUSH Rn. On x86, it would be MOV
RCX,[pserver] or MOV RCX,Rn.

If the compiler recognised that pserver at that point contained only
&server, then it could perhaps optimise. But on x86 you can't directly
push an address (neither when static, nor when the offset of a local
frame variable); it would be two instructions. On x86, it would be MOV
RCX,&server or LEA RCX,[...].

> Now do you understand my request for dereferencing ?

There is no dereferencing in this case as a dereference would yield the
entire struct. That is not what is happening. The only dereference
might be the normal one where in a high-level language you write A and
the generated native code is MOV R0,[A] rather than MOV R0,A. But that
is so common that you never even think about it.

--
Bartc

[BartC]

On 01/09/2016 10:55, BartC wrote:
> On 01/09/2016 10:38, R.Wieser wrote:
>> Andy,

> register-resident, it would be PUSH Rn. On x86, it would be MOV
> RCX,[pserver] or MOV RCX,Rn.

> frame variable); it would be two instructions. On x86, it would be MOV
> RCX,&server or LEA RCX,[...].

I meant x64 for these two. x64 passes the first 4 or 6 arguments in
registers.

--
Bartc

[R.Wieser]

Jerry,

> Yes, but you only posted partial code, and even then you changed the
> types, function names, etc. Are we supposed to read your mind as to
> what the code *really is*? I don't think so.

Nope. I posted all the code that was involved in the problem. And yes, I
changed the type. On purpose, because that type is the one I needed in the
receiving function.

As for the function name, do you think you would have been more happy with
"write" (as in to an open (file) handle) ? I think you would have been
none-the-wiser than you are now -- but most likely would go on a (unwanted!)
tangent on how I should not be writing the contents of that "hostent"
structure to somewhere that way ...

> But you have a problem because you're not passing an unsigned
> char * to the function; rather you're passing a hostent*.

So, you are trying to tell me me that the "(unsigned char*)" actually
doesn't do anything at all ? Really ?

As far as I'm concerned the "unsigned char *" and "hostent*" typing just
tell you the "preferred usage" of the data pointed to by the address
involved. Nothing more.

And no, that turned out not the be the problem *at all*.

> The two are *not the same thing*.

Well, not to the compiler. To the machine the executable is going to run
on ? It does not even have any concept of data typing. :-)

Regards,
Rudy Wieser

Jerry Stuckle <jstu...@attglobal.net> schreef in berichtnieuws

nq58a5$akc$1...@jstuckle.eternal-september.org...

[R.Wieser]

Jerry,

> It WORK'S WHEN YOU DO IT RIGHT.

THAN TELL ME HOW TO FIGURE OUT WHAT I DID WRONG

.... instead of keeping hammering me that it *should* work, but not coming
up with *any* "hey, try this. What result do you get ?" that could shed
light on what the problem might be.

Heck, now, with 20-20 vision I can tell that just a few lines of example
code could have made clear where I was taking a wrong turn.

The only reason I did not try to write such code myself (yes, did think
about it) is that, atb that time, I did not assume I understood enough of
indirection to be able to write such a testing without running into the same
problem.

Regards,
Rudy Wieser


-- Origional message:

Jerry Stuckle <jstu...@attglobal.net> schreef in berichtnieuws

nq58g7$akc$2...@jstuckle.eternal-september.org...

[R.Wieser]

Jerry,

> Yes, we READ it. But you posted INCOMPLETE and
> INCORRECT information.

Go blow a horse. Incomplete ? You simply are not capable of working
with the info you got.

The info was-and-is correct. And no, you not being capable to understand
why someone would make such a typecast doesn't make it incorrect, it only
indicates you have a limited imagination.

Regards,
Rudy Wieser


-- Origional message:

Jerry Stuckle <jstu...@attglobal.net> schreef in berichtnieuws

nq58ll$akc$3...@jstuckle.eternal-september.org...

[R.Wieser]

Reinhardt,

> Problem of comprehensive reading?

I don't think so.

> Since do never showed any prototype for your function, we
> do not know

Yes you do.

And if you look at your own quoted material I've explained why, and how.

Short explanation: if the offered parameter and the receiving argument have
different types the compiler would throw an error. Thus the prototype can
be inferred from the call, which I included in my inital post.

Apart from that, what other info do you think you need ? And if you say
"just all of the rest of your code" I'm going to presume you have no clue,
and are just on a fishing expedition.

And what is it with you guys that when I tell you that that code is of no
consequence to the problem you simply *refuse* to accept that ?

What if I would tell you that that "foobar" function opens a pipe, sends
bytes thru it (pointed to by the first argument, with the second argument to
the foobar function being the ammount) and than closes the pipe ? How
would that help to get the problem into focus ? I don't think it would.
Hence me not including it.

Believe me, I've got enough experience in seeing threads being poissoned by
people who want to talk about *everything* in regard to the offered (full)
code, but for the problem the code was posted for.

> At least your self confidence does not seem to be lacking.

You say that as if its a bad thing. :-)

Regards,
Rudy Wieser

-- Origional message:
Reinhardt Behm <rb...@hushmail.com> schreef in berichtnieuws

nq5n7g$d5k$1...@dont-email.me...

[David Brown]

On 01/09/16 13:36, R.Wieser wrote:

>> At least your self confidence does not seem to be lacking.
>
> You say that as if its a bad thing. :-)
>

In this case, it /is/ a bad thing. Misplaced self-confidence is
stopping you from learning.


It is pretty clear from the this thread that you are missing some
important understandings about pointers in C++. Other people have given
you various explanations, all of which would have made sense to you if
you understood the basics here. But you don't know the difference
between addresses and objects, or how to get from one to the other.

Ignorance is a solvable problem - ask the right questions, listen to the
answers, and learn. But pig-headed ignorance, an insistence that you've
tried everything already, and insulting people who try to help you -
that is not going to fix anything.

So if you really want to learn, you have two choices. One is to go away
and study C++ - read some books, take some courses, and learn the
language. The other is to ask appropriate questions, and work
/politely/ and /respectfully/ with people who are willing to spend their
free time helping others.

However you are working, a key point is to get a small, self-contained
code snippet that illustrates your problem. It must contain /all/
relevant information - the information that other people tell you is
relevant, not just the bits that /you/ think are relevant. A good guide
is to use this site with an online code editor and compiler:

<http://gcc.godbolt.org/#>

Your snippet is ready when people can paste it directly into that page,
and either compile the code or see exactly what error message is causing
you trouble.


After the way you have treated some of the group's regulars, I'd be
surprised if they bothered to try to help you again - but there will be
some people who will give you hints once you have posted code.

[R.Wieser]

Bart,

> > Heck, why do you think both "." and "->" exist to access
> > a strucures fields ?
>
> "P -> m" is just a neater way of writing of (*P).m.

I read that too. So, should than (*P) not return the addres of the
structure itself ?

As mentioned in my first message, that does not even pass the compiler.

> S.m means that S is a struct, not a pointer.

To me "S" is just a static, typed address of a struct. Put simpler: If its
referring to something thats stored in memory than its a pointer, otherwise
its a constant. I guess my other languages knowledge is interfering here.
:-\

> In your OP, you didn't give the declaration of the function that
> you want to pass your struct pointer to

Currently two other people said the same, and I give you the same answer: As
far as I can tell the declaration of that function can be inferred from the
way I called it: if the offered parameter does not match the receiving
arguments type the compiler will throw an error.

> (nor of the struct itself),

Really ? You mean that, next to having posted how I declared that
"server" variable, I should have copy-pasted the contents of the header-file
regarding to the "hostent" structure too ?

> so it's difficult to know exactly how it ought to be passed.

I'm not sure which problem you might be referring to. Mind you, I already
mentioned that the call as proveded in the OP did work. That means
including that typecasting.

Regards,
Rudy Wieser


-- Origional message:

BartC <b...@freeuk.com> schreef in berichtnieuws nq6a4l$rb$1...@dont-email.me...

[R.Wieser]

BartC,

> The definition for pserver was as a pointer variable initialised
> to the address of a struct (&server).

And as the contents of "pserver" are most likely stored somewhere in memory
"pserver" is a pointer in itself -- to its contents. Contents which in
turn point to the memory where the structure resides.

> On x86, a push of that variable would be of the
> form PUSH [pserver].

Correct. And I don't know about you, but to me that looks like
dereferencing.

> There is no dereferencing in this case as a dereference
> would yield the entire struct.

So, the result of that above push is infact the whole structure ? I
don't think so. To me it looks that what you would have on the stack is
simply the address of (aka: a pointer to) where the structure is stored in
memory.

But I think this is a semantics problem: High-level programmers often
confound the name of a variable with its contents. In cases like this that
does throw a wrench into my understanding what the blazes is actually ment.
:-\

Regards,
Rudy Wieser


-- Origional message:

BartC <b...@freeuk.com> schreef in berichtnieuws nq8tvc$2ri$1...@dont-email.me...

[Chris Vine]

On Thu, 1 Sep 2016 14:15:27 +0200
"R.Wieser" <add...@not.available> wrote:
> Bart,
>
> > > Heck, why do you think both "." and "->" exist to access
> > > a strucures fields ?
> >
> > "P -> m" is just a neater way of writing of (*P).m.
>
> I read that too. So, should than (*P) not return the addres of the
> structure itself ?

See below.

> As mentioned in my first message, that does not even pass the
> compiler.
>
> > S.m means that S is a struct, not a pointer.
>
> To me "S" is just a static, typed address of a struct. Put simpler:
> If its referring to something thats stored in memory than its a
> pointer, otherwise its a constant. I guess my other languages
> knowledge is interfering here. :-\

Why don't you stop arguing and get out a book.

Your "to me ..." is ridiculous. It doesn't matter what 'S' is to you,
it is what the C or C++ standards specify which counts.

'(*P)' does not "return the addres (sic) of the structure"; it does
the opposite. '*' is the dereferencing operator, and *P evaluates to
the struct pointed to by 'P'. 'P' is a pointer. Pointers hold
addresses. You have repeatedly been told this. You repeatedly think
you know better. You don't. You also have an misconceived (and I
think probably entirely inverted) notion of what the word "dereference"
means.

The 'S' in 'S.m' is not "just a static, typed address of a struct". 'S'
is the name of a variable which represents the struct itself. '.' is
the dot operator providing access to the members of that struct. The
'->' operator happens to dereference a pointer to a struct and provide
access to the members of the struct at the same time.

Your stubborn refusal to actually learn the language (and indeed to
read the answers you have been given) and instead endlessly to
hypothesise about it is astonishing.

[R.Wieser]

David,

> In this case, it /is/ a bad thing. Misplaced self-confidence
> is stopping you from learning.

Ah, right. It *must* be my self-confidence thats misplaced, because
*your're* confident that yours isn't.

Lolz.

> Ignorance is a solvable problem - ask the right questions, listen
> to the answers, and learn.

I certainly learned something: If I indicate that the suggested answer does
not work than quite a number of "helpers" will respond with (the equivalent
of) "Yes it does!", without actually trying to figure out what goes wrong.

> and insulting people who try to help you -

You want to talk about *insulting* ? Than put yourself in my position, and
think what you would feel when people just go "Yes it does!" on you.

And than lets not talk about several times suggesting stuff I already
mentioned, in the initial post, that didn't work. And, with my apologies
if I have missed something there, a few people have asked me what the called
functions prototype looks like, when that could have easily be inferred from
the info I already had provided.

I've goddamit tried *every* suggestion that has been made, and have posted
back the resulting errors. What did *you* learn from those ? Nothing.
No "try this" or "try that". Just a lot of repeating whats in those
cherished C++ books without having a clue how to deal with what to do if a
suggestion doesn't work. Infuriating.

You want to tell me how to learn ? Ha! Take a look at your own navel, and
try to learn how to teach !

Arrogant nitwit.

Regards,
Rudy Wieser


-- Origional message:

David Brown <david...@hesbynett.no> schreef in berichtnieuws
nq959o$q26$1...@dont-email.me...

[Fred.Zwarts]

"R.Wieser" schreef in bericht
news:57c81b14$0$918$e4fe...@news.xs4all.nl...
>
>Bart,

After reading the whole discussion, I think here is the basic problem. Your
terminology differs from what is normal when discussing C++ (or C) things.
This is often a problem when you enter a new field. The first thing to learn
is the terminology, in particular when words are used differently in the new
field than in daily life.
That is why several people suggested to read a beginners book on C++ (or C).
It teaches at least the right terminology, so that you are able to formulate
your remaining questions in such a way, that experts in the field understand
what you mean.

You did not quote the declarations, which I repeat here.

struct X S;
struct X *P = &S;

>
>> > Heck, why do you think both "." and "->" exist to access
>> > a strucures fields ?
>>
>> "P -> m" is just a neater way of writing of (*P).m.
>
>I read that too. So, should than (*P) not return the addres of the
>structure itself ?

P is a pointer and (following the normal terminology) P contains already the
address of the struct, not the struct itself.
When the pointer is dereferenced, using the * operator, as in (*P), this is
refers no longer to an address, but to the whole object of the struct, which
may occupy several memory addresses. So, indeed, (*P) does not return the
address of the object, but the object itself.
Some operators operate on objects, not on addresses. One of them is the .
operator, which selects a member within the object.
You cannot select a member of a address, so P.m does not make sense, but S.m
makes sense, because S refers to an object, but P does not..
To get a member from an pointer (which following normal terminology is
equivalent to an address) to an object, you first need to dereference the
pointer using the dereferencing operator *, to get the object (*P) then
apply the member select operator . and then name the member to be selected.
So: (*P).m and the -> operator does these two operations in one shot,
therefore (*P).m is equivalent to P->m.

>
>As mentioned in my first message, that does not even pass the compiler.

Of course (*P) does not pass the compiler, because the compiler expects a
pointer as the parameter, not an object, (a dereferenced pointer is an
object).

>
>> S.m means that S is a struct, not a pointer.
>
>To me "S" is just a static, typed address of a struct. Put simpler: If
>its
>referring to something thats stored in memory than its a pointer, otherwise
>its a constant. I guess my other languages knowledge is interfering
>here.
>:-\

Again, you are using the wrong terminology here. When talking to C++
experts, it is better to try to use the same terminology to prevent
misunderstanding.
An object has a starting address, but the name S here refers to the whole
object, which may occupy several memory addresses. S does not refer only to
its starting address. Therefore, we do not call S a pointer. P is a pointer
which contains the starting address of the object.

So, if for you "S" is just a static, typed address of a struct, then you are
wrong, when using the normal terminology. S is not a pointer, not an
address, but the whole object. A pointer in normal terminology refers to a
memory location that contains the address of an object. Of course you can
use your own terminology, but then the misunderstandings will continue.

All symbols for objects used in C++ refer to objects ultimately stored in
memory, but not all objects are pointers.
The normal terminology is that a pointer is an variable which refers to a
memory location that may contain the starting address of another object.
Objects that contain other information than a single address are not called
a pointer. A pointer adds a level of indirection.

[Ben Bacarisse]

"R.Wieser" <add...@not.available> writes:
this is the attribution:
> David,
<snip>

>> Ignorance is a solvable problem - ask the right questions, listen
>> to the answers, and learn.
>
> I certainly learned something: If I indicate that the suggested answer does
> not work than quite a number of "helpers" will respond with (the equivalent
> of) "Yes it does!", without actually trying to figure out what goes
> wrong.

It's generally regarded as your job to tell the world what goes wrong
with a suggested solution. Saying is "does not work" and then expecting
everyone else to "figure out what goes wrong" is not the best way to
move forward.

Of course you are sometimes completely lost -- so lost you can say not
more than that something does not work. But in those cases you need to
go back and ask another, often simpler, question.

<snip>
--
Ben.

[Ben Bacarisse]

"R.Wieser" <add...@not.available> writes:
<snip>

> But I think this is a semantics problem: High-level programmers often
> confound the name of a variable with its contents.

Maybe they do, but in this case the confusion seems, instead, to be
about the value of an expression. Everyone whose posts I've read was
clear that "server" was the name of a variable (more accurately an
object). The confusion (and it seemed to be only yours) was about what
value was contained in the object named "server".

In your original code snippet, "server" was declared to have type
"pointer to struct hostent", so simply writing the name server as a
primary expression in the function call satisfied what you said you
wanted -- to pass the address of the whole structure to the function.
But you seemed to either dispute the truth of that or to say that it did
not work in some unstated way.

Anyway, if it is all resolved now, maybe you could post the code
fragment that does what you wanted so I can see what it is that's wrong
with the answers you got.

<snip>
--
Ben.

[BartC]

On 01/09/2016 13:37, R.Wieser wrote:
> BartC,
>
>> The definition for pserver was as a pointer variable initialised
>> to the address of a struct (&server).
>
> And as the contents of "pserver" are most likely stored somewhere in memory
> "pserver" is a pointer in itself -- to its contents. Contents which in
> turn point to the memory where the structure resides.
>
>> On x86, a push of that variable would be of the
>> form PUSH [pserver].
>
> Correct. And I don't know about you, but to me that looks like
> dereferencing.
>
>> There is no dereferencing in this case as a dereference
>> would yield the entire struct.
>
> So, the result of that above push is infact the whole structure ? I
> don't think so. To me it looks that what you would have on the stack is
> simply the address of (aka: a pointer to) where the structure is stored in
> memory.
>
> But I think this is a semantics problem: High-level programmers often
> confound the name of a variable with its contents. In cases like this that
> does throw a wrench into my understanding what the blazes is actually ment.
> :-\

I think you're mixing up implicit 'dereferencing' done in the native
code (which is a just an ordinary, non-immediate memory access), and
explicit dereferencing as it appears in C code using "*" (probably in
C++ too; I'm not familiar with that language but your examples can be
explained in C terms).

C:

int A; // int
int *B; // pointer to int
struct S C; // struct
struct S *D; // pointer to struct

A; // evaluate A: MOV R0,[A]
B; // evaluate B: MOV R0,[B]
*B // dereference B: MOV R0,[B]; MOV R0,[R0]
C; // evaluate C: <LOAD STRUCT [C]>
D; // evaluate D: MOV R0,[D]
*D; // dereference D: MOV R0,[D]; <LOAD STRUCT [R0]>

So 'dereference', as understood in the language, occurs only twice. But
the [...] address mode, which you like to call a dereference, occurs
every time.

The <LOAD STRUCT> code depends on the compiler; if you have a 256-byte
struct then clearly you can't load the lot into a register. The
implementation might just manipulate a pointer to the struct (&C or D),
but you don't need to concern yourself with that. Not unless you want to
write ASM instead of HLL.

--
Bartc

[David Brown]

On 01/09/16 15:10, R.Wieser wrote:
> David,
>
>> In this case, it /is/ a bad thing. Misplaced self-confidence
>> is stopping you from learning.
>
> Ah, right. It *must* be my self-confidence thats misplaced, because
> *your're* confident that yours isn't.
>

You might notice that I haven't made /any/ claims about C++ or my
knowledge of it - I am merely pointing out that the problems /you/ have.

> Lolz.
>
>> Ignorance is a solvable problem - ask the right questions, listen
>> to the answers, and learn.
>
> I certainly learned something: If I indicate that the suggested answer does
> not work than quite a number of "helpers" will respond with (the equivalent
> of) "Yes it does!", without actually trying to figure out what goes wrong.
>
>> and insulting people who try to help you -
>
> You want to talk about *insulting* ? Than put yourself in my position, and
> think what you would feel when people just go "Yes it does!" on you.

I've read the posts in this thread. It is very clear that you are an
angry man who is trying to program in an unfamiliar language by jumping
straight in and making assumptions - and then fighting tooth and claw
with everyone who tells him he is wrong. Maybe you are frustrated over
failing to get anything working - but lashing out and insulting those
who try to help you is not going to work.

>
> And than lets not talk about several times suggesting stuff I already
> mentioned, in the initial post, that didn't work.

You have claimed, repeatedly, to have tried people's suggestions. But
clearly you have misunderstood them, or not tried hard enough - you have
been given information on the differences between objects and pointers,
and the meaning of "dereference". If you were to actually follow the
suggestions and post some code, people could correct it precisely and
give you exactly the code you need. But you seem to prefer arguing to
learning.

> And, with my apologies
> if I have missed something there, a few people have asked me what the called
> functions prototype looks like, when that could have easily be inferred from
> the info I already had provided.

No, they cannot infer the prototypes. They can infer some things about
the prototypes, but not the full prototypes.

And anyway, it is /you/ who needs the help - minimising the effort
needed by others (who are providing /free/ advice) is basic courtesy.

>
> I've goddamit tried *every* suggestion that has been made, and have posted
> back the resulting errors. What did *you* learn from those ? Nothing.
> No "try this" or "try that". Just a lot of repeating whats in those
> cherished C++ books without having a clue how to deal with what to do if a
> suggestion doesn't work. Infuriating.
>
> You want to tell me how to learn ? Ha! Take a look at your own navel, and
> try to learn how to teach !
>
> Arrogant nitwit.
>

Well, that's yet another member of this group who will not bother
helping you.

[R.Wieser]

Chris,

> > To me "S" is just a static, typed address of a struct. Put simpler:
> > If its referring to something thats stored in memory than its a
> > pointer, otherwise its a constant. I guess my other languages
> > knowledge is interfering here. :-\
>
> Why don't you stop arguing and get out a book.

Which one ? The one who tells me exactly what I mentioned in the above, or
the one you are thinking of supposedly saying something different ?

> Your "to me ..." is ridiculous.

So is you guys confounding of variables and their contents ridiculous to me.
And confusing.

> '(*P)' does not "return the addres (sic) of the structure"; it
> does the opposite.

So it *doesn't* return the addres of the structure .....

> '*' is the dereferencing operator, and *P evaluates to
> the struct pointed to by 'P'.

.... but it returns a whole structure ....

> 'P' is a pointer. Pointers hold addresses. You have
> repeatedly been told this.

... even though a pointer just holds an address.

Yeah, *that* sounds logical. Not.

> The 'S' in 'S.m' is not "just a static, typed address of a
> struct". 'S' is the name of a variable which represents
> the struct itself.

Thats what I said !

> '.' is the dot operator providing access to the members
> of that struct.

... add offset of member to base address of struct and retrieve the
pointed-to data. Yeah, sound good to me.

> Your stubborn refusal to actually learn the language

Lol, why did you think I was asking my question here, and not directly
ditched the whole thing ? Because I wanted to keep you guys busy ?
Yeah, that must be it ....

> (and indeed to read the answers you have been given)

It always amazes me how someone can claim that when I know for a fact that I
have responded to every post made to me, while at the same time showing to
me *he* didn't read the posts, otherwise he would have known. :-)

... but than again, you actually ment "read the answers" as "agree with us",
didn't you ?

I have no problem with agreeing with someone *provided* that what they say,
in this case, match with what I see happening infront of me. As long as
that does not happen, fat chance.

> and instead endlessly to hypothesise about it is astonishing.

Did I have another choice ? None of the provided suggestions here gave
the expected result. Or should I perhaps have asked for devine
intervention ?

Regards,
Rudy Wieser


-- Origional message:

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> schreef in berichtnieuws
20160901133...@bother.homenet...

[BartC]

On 01/09/2016 13:15, R.Wieser wrote:
> Bart,
>
>>> Heck, why do you think both "." and "->" exist to access
>>> a strucures fields ?
>>
>> "P -> m" is just a neater way of writing of (*P).m.
>
> I read that too. So, should than (*P) not return the addres of the
> structure itself ?


> As mentioned in my first message, that does not even pass the compiler.
>
>> S.m means that S is a struct, not a pointer.
>
> To me "S" is just a static, typed address of a struct. Put simpler: If its
> referring to something thats stored in memory than its a pointer, otherwise
> its a constant. I guess my other languages knowledge is interfering here.
> :-\

I think you're getting confused with the concept of a 'variable'. (Where
you an ASM programmer?)

Suppose you write this:

int A;

Is "A", as encountered in an expression, the static, typed address of an
int variable? Or the value of that variable?

In ASM "A" would be the address of the int (&A) in C terms.

But in practically every HLL, an automatic dereference takes place,
equivalent to *(&A) in C terms. In C the * and & cancel to leave you
with just A, which is how everyone already uses variables in HLLs.

S obeys the same rules.

(However, array names have funny rules of their own in C and C++; then
you *will* get confused! Fortunately this is about structs.)

>> so it's difficult to know exactly how it ought to be passed.
>
> I'm not sure which problem you might be referring to.

If the function being called takes a 'pointer to S', and you passed it a
'pointer to S' then there should have been no problem. If there was in
fact a problem, then more information is needed. (Sometimes a compiler
will tell you what type was expected, and what type was instead
encountered.)


--
Bartc

[BartC]

On 01/09/2016 15:05, R.Wieser wrote:
> Chris,
>
>>> To me "S" is just a static, typed address of a struct. Put simpler:
>>> If its referring to something thats stored in memory than its a
>>> pointer, otherwise its a constant. I guess my other languages
>>> knowledge is interfering here. :-\
>>
>> Why don't you stop arguing and get out a book.
>
> Which one ? The one who tells me exactly what I mentioned in the above, or
> the one you are thinking of supposedly saying something different ?
>
>> Your "to me ..." is ridiculous.
>
> So is you guys confounding of variables and their contents ridiculous to me.
> And confusing.
>
>> '(*P)' does not "return the addres (sic) of the structure"; it
>> does the opposite.
>
> So it *doesn't* return the addres of the structure .....
>
>> '*' is the dereferencing operator, and *P evaluates to
>> the struct pointed to by 'P'.
>
> .... but it returns a whole structure ....

struct S P; // P is a pointer to S

&P; // yields pointer to pointer to S
P; // yields pointer to S
*P; // yields S (the whole struct)
**P; // error: *P is not a pointer

P.m; // error: P is a pointer not a struct
(*P).m // yields the member m; also P->m)
&((*P).m) // yields address of member m; also &(P->m)

--
Bartc

[R.Wieser]

Ben,

> It's generally regarded as your job to tell the world what
> goes wrong

If I knew that I would probably have had the answer too.

Instead all I could do is to tell *where* it went wrong.

> with a suggested solution.

I did. And I mentioned that that didn't work. I also included something
that *did* work (should, in retrospect, have stopped all the "but what does
the prototype of your function look like", but no).

> Saying is "does not work" and then expecting everyone
> else to "figure out what goes wrong" is not the best way to
> move forward.

Absolutily, and I should apologize for that. I should have mentioned that
just using "server" gave *a* result, just not the one matching with
"server->h_addr".

As a result I thought that I was looking at the contents of the "server"
variable holding the pointer to the hostent structure, and not the hostent
structure itself.

In the end it turned out that "server->h_addr" wasn't pointing anywhere near
the hostent structure, and definitily not at its start.

Worse, I've mentioned the very same to others, and now I'm stumbled into
that same pit. Bit of a wake-up call. :-(

To be honest, I thought someone here would know a simple debugging approach
which would pinpoint where it went wrong. At least, thats the approach I
always use.

> But in those cases you need to go back and ask
> another, often simpler, question.

Remind me next time when I'm waist-deep into a "this should work", "sorry,
doesn't for me" cycle. :-)

Also, you guys are invited to do the same. Ask simple(r) questions I mean.
:-)

Regards,
Rudy Wieser


-- Origional message:

Ben Bacarisse <ben.u...@bsb.me.uk> schreef in berichtnieuws
87eg53v...@bsb.me.uk...

[Ben Bacarisse]

BartC <b...@freeuk.com> writes:
<snip>

> struct S P; // P is a pointer to S

You meant

struct S *P;

which is important since this whole thread revolves around what is and
is not a pointer!

> &P; // yields pointer to pointer to S
> P; // yields pointer to S
> *P; // yields S (the whole struct)
> **P; // error: *P is not a pointer
>
> P.m; // error: P is a pointer not a struct
> (*P).m // yields the member m; also P->m)
> &((*P).m) // yields address of member m; also &(P->m)

This can be written as &(*P).m and &P->m since postfix operators (like
. and ->) bind more tightly than prefix ones like (& and *). Your
parentheses help here, since the whole point is exposition; I'm just
pointing out you don't always need so many of them.

--
Ben.

[Scott Lurndal]

"R.Wieser" <add...@not.available> writes:
>BartC,
>
>> The definition for pserver was as a pointer variable initialised
>> to the address of a struct (&server).
>
>And as the contents of "pserver" are most likely stored somewhere in memory
>"pserver" is a pointer in itself -- to its contents. Contents which in
>turn point to the memory where the structure resides.

This is your fundamental misunderstanding.

The address of pserver (&pserver) is the address of a four or eight
byte (32-bit or 64-bit) field that contains the address of the data.

There are two levels of indirection here. First, one must load
the pointer from &pserver into a register, then one loads the
data pointed to by pserver using that register. So there are two
addresses:

1) The address of the pointer
2) The address of the data that the pointer points to.


sim> md8 0x1000 12
0000000000001000: 0000000000001040 0000000000000000 ................
0000000000001010: 0000000000000000 0000000000000000 ................
0000000000001020: 0000000000000000 0000000000000000 ................
0000000000001030: 0000000000000000 0000000000000000 ................
0000000000001040: 676f6f672e777777 00006d6f632e656c www.google.com..
0000000000001050: 0000000000000000 0000000000000000 ................

So, the address of 'pserver' is 0x1000
The address of the structure pointed to by pserver is 0x1040
(whose first field (h_name) contains the host name 'www.google.com'.)

printf("%p %p\n", &pserver, pserver)

0x1000 0x1040

(note: numeric data printed as little-endian 64-bit words, LP64)

[BartC]

On 01/09/2016 15:36, Ben Bacarisse wrote:
> BartC <b...@freeuk.com> writes:
> <snip>
>> struct S P; // P is a pointer to S
>
> You meant
>
> struct S *P;
>
> which is important since this whole thread revolves around what is and
> is not a pointer!

Yes, thanks.

--
Bartc

[Richard]

[Please do not mail me a copy of your followup]

BartC <b...@freeuk.com> spake the secret code

<nq8rmu$r82$1...@dont-email.me> thusly:

So if I understand you correctly, I can make a call to a function
defined in a DLL with gcc. I can't call functions that I haven't
declared and I have no header file for the function, so I have to
manually declare the function myself. (In other words, I just
re-implemented a part of the header.) In order to do that, I have to
demangle the exported name from the DLL in order to understand things
like const qualifies on arguments and return types, as well as any
namespaces used on the types and surrounding the function itself.
Furthermore, if custom types are used as the input arguments or as
the output arguments I have to somehow deduce the declarations of
those types. That information won't be present in any form in the
mangled names of the exported functions (other than the name of the
custom type).

Are you saying that by merely supplying the DLL to the compile phase
that I get all of the above from gcc/g++?

When linking I have to tell gcc to link against the DLL and not the
import library for the DLL as I would with MSVC (because I don't have
the import library; I only have the DLL). In this case, it's a
fairly easy thing to match up undefined symbols (that are name
mangled) to the export symbol list of a DLL and mark the resulting
linked output as having an import dependency on the DLL and put the
matching symbol in the import table.

So while it seems pretty straightforward to simply link directly
against the DLL instead of the import library as MSVC does it, the
actual compiling step seems non-trivial.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Jerry Stuckle]

On 9/1/2016 6:22 AM, R.Wieser wrote:
> Jerry,
>
>> Yes, but you only posted partial code, and even then you changed the
>> types, function names, etc. Are we supposed to read your mind as to
>> what the code *really is*? I don't think so.
>
> Nope. I posted all the code that was involved in the problem. And yes, I
> changed the type. On purpose, because that type is the one I needed in the
> receiving function.
>

You posted all the code YOU THINK was involved in the problem. But once
again, you were wrong (and still are).

> As for the function name, do you think you would have been more happy with
> "write" (as in to an open (file) handle) ? I think you would have been
> none-the-wiser than you are now -- but most likely would go on a (unwanted!)
> tangent on how I should not be writing the contents of that "hostent"
> structure to somewhere that way ...
>

I would have been happy with the *real code*. It would have solved your
problem in one post - instead of this continuing bullshit.

>> But you have a problem because you're not passing an unsigned
>> char * to the function; rather you're passing a hostent*.
>
> So, you are trying to tell me me that the "(unsigned char*)" actually
> doesn't do anything at all ? Really ?
>

It means you are lying to the compiler. Not a good thing.

> As far as I'm concerned the "unsigned char *" and "hostent*" typing just
> tell you the "preferred usage" of the data pointed to by the address
> involved. Nothing more.
>

And you are wrong (again).

> And no, that turned out not the be the problem *at all*.
>

No, your misuse was not the problem.

>> The two are *not the same thing*.
>
> Well, not to the compiler. To the machine the executable is going to run
> on ? It does not even have any concept of data typing. :-)
>

Just to the compiler is enough. It's trying to tell you that you
screwed up. But you are too bull-headed to admit it - or try to lean
the *correct way* to program.

And not necessarily to the underlying machine, either.

> Regards,
> Rudy Wieser

[BartC]

On 01/09/2016 19:57, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> BartC <b...@freeuk.com> spake the secret code
> <nq8rmu$r82$1...@dont-email.me> thusly:
>
>> On 31/08/2016 21:33, Richard wrote:
>>> [Please do not mail me a copy of your followup]

[Did I do that?]

No. The compilation stage (from .c to .o for example) will still need a
header file which describes the functions that are to be called.

The link stage (which can be invoked by gcc but it will use the 'ld'
linker) doesn't need a .lib or .a file; it can directly use the .dll
library itself.

So to use a third party library, you will need at least a .dll and .h
file. You don't need .lib too (an advantage as .lib formats are often
different across compilers, but .dll files necessarily have to be
compatible).

--
Bartc

[Vir Campestris]

On 01/09/2016 10:38, R.Wieser wrote:
> Andy,
>
>> > Can you read assembler?
> I think so.
>
>> > bar(pserver); /* Disassembly will show a single push of */
>> > /* a 32 or 64 bit address onto the stack */
> You're cheating here. :-)
>
> The devil is in the details.
>
> PUSH pserver
>
> is quite a bit different than
>
> PUSH [pserver]
>
>> > pserver is on any architecture you are likely to come across
>> >a single register containing the address of server.
> Correct.
>
> Though under Assembly "pserver" is nothing more than a design-time label,
> being converted at compile-time to a fixed address pointing at a bit of
> memory where its 'contents' are stored. Contents which than point to the
> actual "server" record.
>

> Now do you understand my request for dereferencing ?
>

> This is basic Assembly. Talk to your teachers. :-)

My apologies.

Compile it, and look at the disassembly. Calling a function with a
struct (not a struct pointer) will copy the struct onto the stack.

Andy

[Vir Campestris]

On 01/09/2016 11:39, R.Wieser wrote:
> Jerry,
>
>> > It WORK'S WHEN YOU DO IT RIGHT.
> THAN TELL ME HOW TO FIGURE OUT WHAT I DID WRONG

Jerry is in my plonk list.

If Alf or Victor reply, on the other hand - you should ignore me. They
_really_ know their stuff.

Andy

[David Brown]

On 01/09/16 21:16, BartC wrote:
> On 01/09/2016 19:57, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> BartC <b...@freeuk.com> spake the secret code
>> <nq8rmu$r82$1...@dont-email.me> thusly:
>>
>>> On 31/08/2016 21:33, Richard wrote:
>>>> [Please do not mail me a copy of your followup]
>
> [Did I do that?]

I think Richard has that as a standard header on all of posts. It seems
a bit unnecessary to me, but maybe he has been bothered by it in the past.

There are significant differences between using a .dll and using a .lib
library (or .so and .a, in *nix terms). A dll is a dynamic library - it
is loaded at run time (/not/ at link time), and requires the dll to be
present on the system when running the program. The calling conventions
are, as you say, standardised for the system and independent of the
compiler (or programming language). But that also means much more
overhead in calling functions in the dll than with statically linked
libraries (.lib and .a) that are part of the compiled executable.

Use a dll if any of the following are true:

1. It's all you've got.
2. You want to share a significant body of code between different
executables.
3. You want to be able to ship or update the library and the application
independently.
4. You have different licensing for the library code and the application
code.
5. Your project development teams, build systems, and test systems are
made easier by having the parts separate.
6. You want to write the different parts in different languages or with
different tools.

Otherwise, use a static library. It is more efficient in terms of code
size and run-time speed, and it means you have a single executable at
the end.

[David Brown]

Actually, Jerry has been correct in this thread - and he has not been
the rudest and most unpleasant poster here either (that "honour" goes to
the OP himself). Credit where credit is due.

[Richard]

[Please do not mail me a copy of your followup]

BartC <b...@freeuk.com> spake the secret code

<nq9uqe$mvg$1...@dont-email.me> thusly:

>No. The compilation stage (from .c to .o for example) will still need a
>header file which describes the functions that are to be called.
>
>The link stage (which can be invoked by gcc but it will use the 'ld'
>linker) doesn't need a .lib or .a file; it can directly use the .dll
>library itself.

OK, this is what I was expecting, but the original poster was talking
about having *only* the DLL and no header or import library (what
MSVC calls the small .lib that hooks up the import table in the
linked executable) and just hacking their way along.

To me, this approach is only going to work as long as all the return
types and types of input arguments are simple types. As soon as one
of them is a structure, you can't just limp along only with the DLL.
You need the header.

[BartC]

On 01/09/2016 23:03, Richard wrote:
> BartC <b...@freeuk.com> spake the secret code
> <nq9uqe$mvg$1...@dont-email.me> thusly:
>
>> No. The compilation stage (from .c to .o for example) will still need a
>> header file which describes the functions that are to be called.
>>
>> The link stage (which can be invoked by gcc but it will use the 'ld'
>> linker) doesn't need a .lib or .a file; it can directly use the .dll
>> library itself.
>
> OK, this is what I was expecting, but the original poster was talking
> about having *only* the DLL and no header or import library (what
> MSVC calls the small .lib that hooks up the import table in the
> linked executable) and just hacking their way along.

I didn't get that impression. Still, you don't necessarily need the
header file; documentation will also do. And the docs might also tell
you how to use the library rather than just be a list of function
signatures. (I make extensive use of MS' msdn site in that manner as I
can't use the header file when I don't code in C.)

Without neither .h file nor docs, it sounds like the developers of the
library don't want anyone else to use it!

But this would be a problem with .lib files as well as .dll. The latter
are just a tidy and obvious way of performing build-time linking to
shared libraries without the (to me) extraneous .lib file in the middle.

--
Bartc

[Jerry Stuckle]

On 9/1/2016 6:39 AM, R.Wieser wrote:
> Jerry,
>
>> It WORK'S WHEN YOU DO IT RIGHT.
>
> THAN TELL ME HOW TO FIGURE OUT WHAT I DID WRONG
>

People have been trying to tell you what you did wrong.

ALL YOU HAVE DONE IS ARGUE.

[Geoff]

Rudy is an assembler hacker, not a C hacker. He's always digging into
the Windows libraries and hooking his code into the API functions.
Since the API is documented largely by its headers and the MSDN
documentation refers to those headers he's always delving into the
structs directly. I'm surprised he's doing C++ but his customer
perhaps requires it.

[Geoff]

On Thu, 01 Sep 2016 15:57:06 +0200, David Brown
<david...@hesbynett.no> wrote:

>Well, that's yet another member of this group who will not bother
>helping you.
>
>

This typical of R.Wieser's behavior pattern. Post extracts of code
that can't be compiled or assembled independently by others, don't
post error messages or give their error numbers. He'll state what he
thinks is the problem and when others attempt to answer he tells them
they're not reading his posts or not answering the question or not
understanding the question and blindly offering suggestions. Don't
dare tell him he's asking the wrong question or that his problem lies
elsewhere. For that crime you are an arrogant nitwit. Then after much
inflammation he'll post his solution and it will be admitted the
question was wrong or the solution was self-found and simple.

[Geoff]

On Tue, 30 Aug 2016 21:38:51 +0200, "R.Wieser" <add...@not.available>
wrote:

>For all people that tried to help me find a solution to that "server"
>variable problem, it turns out to be rather simple, and due to a mistake
>made by me.
>

Nothing new here.

>Yes!, I'm one of those people that does not run away when he has made one,
>and comes out openly for it. If you can't handle that, tough shit.
>
>
>But don't think you're without blame here !.
>
>
>From my initial message:
>
>> The only way I was able to do that was to refer to the first
>> (and in this case only) field in that structure:
>>
>> foobar( (unsigned char*) server->h_addr, ... )
>
>*Both* the "first" and "only" descriptions where wrong. Next to that
>"h_addr" isn't even a field in that hostent record, but in a ipv4/ipv6 table
>that the hostent record holds a pointer to, and *noone* here noticed any of
>those three mistakes. Doesn't anybody actually *read* a question before
>replying to it ? :-( :-)
>
>(I was actually thinking of another structure, just holding an ipv4 or ipv6
>address)
>

A fact that would have proved to be obvious had you posted a complete
and correct problem statement WITH the hostent struct:

typedef struct hostent {
char FAR *h_name;
char FAR FAR **h_aliases;
short h_addrtype;
short h_length;
char FAR FAR **h_addr_list;
} HOSTENT, *PHOSTENT, FAR *LPHOSTENT;


So the struct your server pointer was pointing to was the wrong struct
in the first place and given your insistence that your problem
statement was complete and correct this group should have recognized
your error?

The group is supposed to research the hostent struct outside of your
problem statement and determine your error based on incorrect and
incomplete information you provide?

And if they don't do this it's because /they/ didn't read but you
can't be bothered to read beginner tutorials about C++ while at the
same time you admit to being a novice in C++. Then you have the
arrogance to criticize the advice you received based on your own
mistaken belief in the correctness of your problem statement.

I remind you the group is about C++, not about socket programming and
you do the group a disservice if you demand they all be experts of the
structs within the Sockets stack. They were focused on the principles
of C++ and the nature of the semantics of your (incorrectly stated)
problem and your misconceptions about it.

NOTE
From Linux man 3 gethostbyname

struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses */
}
#define h_addr h_addr_list[0] /* for backward compatibility */

From Microsoft's WinSock.h:

struct hostent {
char FAR * h_name; /* official name of host */
char FAR * FAR * h_aliases; /* alias list */
short h_addrtype; /* host address type */
short h_length; /* length of address */
char FAR * FAR * h_addr_list; /* list of addresses */
#define h_addr h_addr_list[0] /* address, for backward
compat */
};

If you had included either of these definitions, as requested, it
would have been obvious to all and to you long ago.

>
>In the end it turned out that "foobar( (unsigned int*) server , ...)" (which
>I had tried long before posting my problem here) actually did give me the
>address of the hostent structure, but as "server->h_addr" and the above
>where not looking at the same spot (remember, I thought that h_addr was the
>first-and-only field in the record) I assumed I was looking at the pointer
>variables data (the addres to the structure) itself (where "server->h_addr"
>showed me, by accident, the expected IPv4 address)
>

*********************************************************************
Note this:
>I do not know anymore who all suggested using just "server", you guys where
>right all along.

Everything in this admission is perfect - then comes the ego:

>Heck, even *I* was right, long before you guys :-)
>
*********************************************************************

Since you were right long before everyone else, the entire thread need
never have been started except you posted the question and then
rejected every bit of advice you received and insisted "it doesn't
work" throughout.

>For all who suggested "*server" or "server->". Sorry, no go.
>
>
>My apologies for not having played a subdued novice all along, but heck, do
>you guys fail at reading and trying to figure out what could have gone wrong
>...

No, the group didn't fail at reading. What they were reading was the
petulant and arrogant rants of someone who thinks he knows more than
the people from whom he is seeking help even while he admits to being
a complete novice on the topic. Pure arrogance.

>
>And no, that does not take anything away from the mistakes I made myself.
>The initial wrong assumption, and having waited so long before
>double-checking if that "h_addr" field was where I thought it would be.

>
>Regards,
>Rudy Wieser
>
>
>-- Origional message:

>R.Wieser <add...@not.available> schreef in berichtnieuws
>57c4895a$0$871$e4fe...@news.xs4all.nl...
>> Hello all,
>>
>> Fair warning: I'm a novice in regard to using C++ (GCC) *and* using linux
>> (lubuntu to be exact). If this is not the newsgroup to be asking
>questions
>> like the below than please advice which newsgroup(s) to use instead.
>>
>> - - - - - -
>> First problem, C++ related:
>>
>> I need to transfer the address of a structure to a function, and have only
>> be able to find a hackish solution for it. The problem is that the
>variable
>> I've got is actually a pointer, and I have no idea how to dereference it.
>>
>> The variable declaration and initialisation in case:
>>
>> struct hostent *server;
>> server = gethostbyname(argv[1]);
>>
>> Now I want to transfer the address stored in the "server" variable to a
>> function. The only way I was able to do that was to refer to the first
>(and
>> in this case only) field in that structure:
>>
>> foobar( (unsigned char*) server->h_addr, ... )
>>
>> I read somewhere that I could use (*server) , but trying it ( (unsigned
>> char*) (*server) ) gave a compile-time error.
>>
>> In short: How do I dereference that "server" variable so the function
>> receives a pointer to the structure ?
>>
>> - - - - - -
>> Second problem, Linux related:

>>
>> As someone wo has spend quite some time on Windows I'm rather accustomed
>> being able to pick a DLL and look inside it to see which functions it
>> exposes that I can use (yeah, I still have to generate a library from it
>and

>> find the function declarations, but thats not the point).
>>
>> I have no idea how to do the same under Linux (and/or how to convert the
>> found functions (system calls ?) to something I can use in C++ ).
>>
>> To be honest, I have no idea if the above is even feasible for C++ (GCC)
>> under linux.
>>
>> I did find an example using "nm", but that only showed the contents of the
>> .o (library) file, and only if the info was not stripped.
>>
>> I also tried that on the full /usr directory, but could not even find
>> "fprint" (found buf_fprint" and "str_fprint" though).
>>
>>
>> And now I'm on a roll asking questions, one thing I did not expect was to
>> find multiple (sometimes over 10) same-named header files , most often of
>> different sizes. Whats the idea behind that, and how should I know which
>> one of those to include ?
>>
>> Regards,
>> Rudy Wieser
>>
>>
>>
>

[Ike Naar]

On 2016-08-30, R.Wieser <add...@not.available> wrote:
> Funny:

>
>> In short: How do I dereference that "server" variable so
>> the function receives a pointer to the structure ?

You seem to be confused about the term "dereferencing".
Given a pointer to an object, dereferencing the pointer gives access
to the object. In C++, one uses the * operator for dereferencing.

What you (seem to) want to achieve is the other way around, given
the object, you seem to want to obtain a pointer to that object.
To achieve that, you take the address of the object, using the &
operator.

ObjectType object;
ObjectType *pointer_to_object = &object; /* taking the address */
ObjectType copy_of_object = *pointer_to_object; /* dereferencing a pointer */

[Vir Campestris]

On 01/09/2016 21:41, David Brown wrote:
> Actually, Jerry has been correct in this thread - and he has not been
> the rudest and most unpleasant poster here either (that "honour" goes to
> the OP himself). Credit where credit is due.

I don't see Jerry's stuff, except where other's post it on. He may have
improved.

Andy

[Gareth Owen]

He hasn't.

[Mr Flibble]

I think it's time I also plonked Stuckle as life's too short to have to
read his consistently egregious posts.

/Flibble