Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #105637 > unrolled thread

Need explanation of C syntax for a Perl 6 guy

Back to article view | Back to comp.lang.c

Contents

  Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-08 20:20 -0800
    Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-08 20:57 -0800
      Re: Need explanation of C syntax for a Perl 6 guy Barry Schwarz <schwarzb@dqel.com> - 2017-03-09 00:46 -0800
    Re: Need explanation of C syntax for a Perl 6 guy gordonb.txjrp@burditt.org (Gordon Burditt) - 2017-03-09 03:29 -0600
      Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-09 12:39 -0800
    Re: Need explanation of C syntax for a Perl 6 guy jt@toerring.de (Jens Thoms Toerring) - 2017-03-09 10:16 +0000
      Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-09 12:40 -0800
      Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-09 13:25 -0800
        Re: Need explanation of C syntax for a Perl 6 guy jt@toerring.de (Jens Thoms Toerring) - 2017-03-10 21:02 +0000
          Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-10 17:49 -0800
    Re: Need explanation of C syntax for a Perl 6 guy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-09 10:22 +0000
      Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-09 12:40 -0800
    Re: Need explanation of C syntax for a Perl 6 guy GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-09 12:48 +0100
      Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-09 12:43 -0800
        Re: Need explanation of C syntax for a Perl 6 guy James Kuyper <jameskuyper@verizon.net> - 2017-03-10 10:22 -0500
          Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-10 11:47 -0800
            Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-10 12:42 -0800
          Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-10 19:52 -0800
    Re: Need explanation of C syntax for a Perl 6 guy raltbos@xs4all.nl (Richard Bos) - 2017-03-09 12:09 +0000
      Re: Need explanation of C syntax for a Perl 6 guy Keith Thompson <kst-u@mib.org> - 2017-03-09 09:05 -0800
    Re: Need explanation of C syntax for a Perl 6 guy John Bode <jfbode1029@gmail.com> - 2017-03-09 12:31 -0800
      Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-09 12:41 -0800
    Re: Need explanation of C syntax for a Perl 6 guy Paul <nospam@needed.invalid> - 2017-03-10 04:06 -0500
      Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-10 12:42 -0800
        Re: Need explanation of C syntax for a Perl 6 guy jt@toerring.de (Jens Thoms Toerring) - 2017-03-10 21:35 +0000
          Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-10 17:48 -0800
        Re: Need explanation of C syntax for a Perl 6 guy John Bode <jfbode1029@gmail.com> - 2017-03-10 14:54 -0800
          Re: Need explanation of C syntax for a Perl 6 guy T <T@invalid.invalid> - 2017-03-10 17:43 -0800
        Re: Need explanation of C syntax for a Perl 6 guy James Kuyper <jameskuyper@verizon.net> - 2017-03-10 21:11 -0500

Page 1 of 2  [1] 2  Next page →

#105637 — Need explanation of C syntax for a Perl 6 guy

Hi C!

I am trying to write some inline C code in Perl 6.  Would
explain to me what is going on in the following two commands:

References:
    https://tronche.com/gui/x/xlib/utilities/XStoreBuffer.html
    https://tronche.com/gui/x/xlib/utilities/XFetchBuffer.html
    man XStoreBuffer

int XStoreBuffer(Display *display, char *bytes,
                  int nbytes, int buffer);

char *XFetchBuffer(Display *display,
                  int *nbytes_return, int buffer);

Questions:
    1) what does the * do to the variable?

    2) what does the * do to the subroutine name?

    3) what is "int nbytes, int buffer"?  Is "buffer"
       the address (pointer) to the buffer? and "nbytes"
       the length of "buffer"?

    4) does "int" stand for "integer"?

    5) does "Display" stand for a special variable or a
       routine?

    6) why does "*display" have a * in front of it?

    7) what does "char" do to "char *XFetchBuffer"?


Many thanks,
-T


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Serious error.
All shortcuts have disappeared.
Screen. Mind. Both are blank.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[toc] | [next] | [standalone]

#105640

On 03/08/2017 08:32 PM, Stefan Ram wrote:
> T <T@invalid.invalid> writes:
>> char *XFetchBuffer(Display *display,
>> Questions:        int *nbytes_return, int buffer);
>>    1) what does the * do to the variable?
>
>   When »T« is a name of a type, »T*« also is a type, called
>   "pointer to T" or "T pointer". It is the type of an address
>   of an object of type T. (Check out the unary operators »*«
>   and »&«.)
>
>   »int« is the name of an integer type, not an abbreviation
>   for "integer".
>

Hi Stefan,

Thank you for the answer.

I am confused.  What is the difference between
»T*« and »*T«.  None of the names in the run string
had asterisks after them, only before them?

How do I tell when something is a regular variable and
when it is a pointer?

Many thanks,
-T

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
Yesterday it worked.
Today it is not working.
Windows is like that.
~~~~~~~~~~~~~~~~~~~~~~~~

[toc] | [prev] | [next] | [standalone]

#105645

On Wed, 8 Mar 2017 20:57:59 -0800, T <T@invalid.invalid> wrote:

>On 03/08/2017 08:32 PM, Stefan Ram wrote:
>> T <T@invalid.invalid> writes:
>>> char *XFetchBuffer(Display *display,
>>> Questions:        int *nbytes_return, int buffer);
>>>    1) what does the * do to the variable?
>>
>>   When »T« is a name of a type, »T*« also is a type, called
>>   "pointer to T" or "T pointer". It is the type of an address
>>   of an object of type T. (Check out the unary operators »*«
>>   and »&«.)
>>
>>   »int« is the name of an integer type, not an abbreviation
>>   for "integer".
>>
>
>Hi Stefan,
>
>Thank you for the answer.
>
>I am confused.  What is the difference between
>»T*« and »*T«.  None of the names in the run string
>had asterisks after them, only before them?

The declarations T* x; or T *x; or even T*x; are all equivalent and
define an object named x that has type pointer to T.  For a pointer
named x, the expression *x in a statement dereferences the pointer and
evaluates to the object the pointer points to.  The expression *T is
not valid in code.

>How do I tell when something is a regular variable and
>when it is a pointer?

A pointer is as much a regular variable as an int or a double.  The
only way to know the type of a variable is to look at its definition.

If you want to write C code, even inline in Perl, it pays to learn the
language.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#105647

> I am trying to write some inline C code in Perl 6.  Would
> explain to me what is going on in the following two commands:

These are functions, not "commands".  C doesn't have "commands"
unless you want to argue about the character strings passed
to the system() function, which ultimately get passed to
a shell for execution, if that is supported.

> References:
>    https://tronche.com/gui/x/xlib/utilities/XStoreBuffer.html
>    https://tronche.com/gui/x/xlib/utilities/XFetchBuffer.html
>    man XStoreBuffer
> 
> int XStoreBuffer(Display *display, char *bytes,
>                  int nbytes, int buffer);
> 
> char *XFetchBuffer(Display *display,
>                  int *nbytes_return, int buffer);
> 
> Questions:
>    1) what does the * do to the variable?

It doesn't do anything to the variable, it is part of the type
before it.  If T is a type, T* is a pointer to that type, T** is a
pointer to a pointer to that type, T*** is a pointer to pointer to
pointer to that type, etc.  The C standard mandates supporting
12 levels of indirection (T************) although if you really
need that many it can get confusing.  Many compilers support an
essentially infinite number of levels of indirection.

If you want a C function to put a value somewhere, you can pass a
pointer to somewhere (often written as &somewhere) in as an argument
to the function.  If the type of somewhere is T, the type of the
pointer you pass in is T *.  This is what is going on with the
nbytes_return argument to XFetchBuffer().  You pass a pointer to
an int in, and the function puts the length of the buffer into that
int.

It does not matter whether you write 
	char *bytes
or
	char* bytes
or
	char          *          bytes
or
	char*bytes
.  The location and size of white space does not matter, although
you can't run adjacent keywords or identifiers together without
some white space.

>    2) what does the * do to the subroutine name?

Nothing.  The * is part of the type before it.  XFetchBuffer returns
a char *, usually stated as "pointer to char" (and sometimes
pronounced "string").

A char * type often points to a C string (which is NUL-terminated,
by definition) but it doesn't have to - it might point to a
fixed-length buffer with no supplied terminator, or perhaps you are
given the length and need to use it to figure out where the end is.

>    3) what is "int nbytes, int buffer"?  Is "buffer"
>       the address (pointer) to the buffer? and "nbytes"
>       the length of "buffer"?

buffer has integer type, NOT a pointer.  Since it's described as
"Specifies the buffer from which you want the stored data returned",
it seems to indicate *WHICH* buffer.  The name "nbytes" strongly
suggests that it is the length you wish to transfer, in bytes.

In Section 16.6 "Using Cut Buffers", linked to from the pages
referenced, it explains that there are 8 cut buffers, numbered 0
through 7.

>    4) does "int" stand for "integer"?

int is a C type, which happens to be a specific integer type.  It
is not an abbreviation for integer, much in the same way that
"Ford", "Chrysler", and "Toyota" do not stand for "automobile".
 
>    5) does "Display" stand for a special variable or a
>       routine?

Display is a special *TYPE*.  Display * is a pointer to that type.
It might be implemented as a typedef defined as a struct.  Or perhaps
as a #define.  Or a union (unlikely, but possible).  You need to
find the definition to be sure.  It's probably in a header file and
in the documentation.  Often, such types are supposed to be opaque
- you should program as though you don't know the implementation
details (such as field names of a struct and what they mean), as
they may vary from system to system.

Note that the Display type might itself be a pointer, or
pointer-to-pointer, etc.  You can't tell this for sure without
looking at the definition or the documentation.

>    6) why does "*display" have a * in front of it?

The * is part of the type before it:  Display *   .  You are supposed
to pass a *POINTER* to the type Display (here the variable for this
is named display), not the whole thing.  You get a pointer to Display
from somewhere, and pass it to functions to specify which Display
to use.  (Some programs may handle more than one Display.)

>    7) what does "char" do to "char *XFetchBuffer"?

char * is the return type of XFetchBuffer.  It returns a pointer
to a character (or in this case, an array of characters).

Incidentally, an * immediately before a type name is an error (at
least usually - someone will point out an odd exception).

You really need to read up on basic C.  I think you're in over
your head trying to write C to interface to Perl.

[toc] | [prev] | [next] | [standalone]

#105688

On 03/09/2017 01:29 AM, Gordon Burditt wrote:
>> I am trying to write some inline C code in Perl 6.  Would
>> explain to me what is going on in the following two commands:
>
> These are functions, not "commands".  C doesn't have "commands"
> unless you want to argue about the character strings passed
> to the system() function, which ultimately get passed to
> a shell for execution, if that is supported.
>
>> References:
>>    https://tronche.com/gui/x/xlib/utilities/XStoreBuffer.html
>>    https://tronche.com/gui/x/xlib/utilities/XFetchBuffer.html
>>    man XStoreBuffer
>>
>> int XStoreBuffer(Display *display, char *bytes,
>>                  int nbytes, int buffer);
>>
>> char *XFetchBuffer(Display *display,
>>                  int *nbytes_return, int buffer);
>>
>> Questions:
>>    1) what does the * do to the variable?
>
> It doesn't do anything to the variable, it is part of the type
> before it.  If T is a type, T* is a pointer to that type, T** is a
> pointer to a pointer to that type, T*** is a pointer to pointer to
> pointer to that type, etc.  The C standard mandates supporting
> 12 levels of indirection (T************) although if you really
> need that many it can get confusing.  Many compilers support an
> essentially infinite number of levels of indirection.
>
> If you want a C function to put a value somewhere, you can pass a
> pointer to somewhere (often written as &somewhere) in as an argument
> to the function.  If the type of somewhere is T, the type of the
> pointer you pass in is T *.  This is what is going on with the
> nbytes_return argument to XFetchBuffer().  You pass a pointer to
> an int in, and the function puts the length of the buffer into that
> int.
>
> It does not matter whether you write
> 	char *bytes
> or
> 	char* bytes
> or
> 	char          *          bytes
> or
> 	char*bytes
> .  The location and size of white space does not matter, although
> you can't run adjacent keywords or identifiers together without
> some white space.
>
>>    2) what does the * do to the subroutine name?
>
> Nothing.  The * is part of the type before it.  XFetchBuffer returns
> a char *, usually stated as "pointer to char" (and sometimes
> pronounced "string").
>
> A char * type often points to a C string (which is NUL-terminated,
> by definition) but it doesn't have to - it might point to a
> fixed-length buffer with no supplied terminator, or perhaps you are
> given the length and need to use it to figure out where the end is.
>
>>    3) what is "int nbytes, int buffer"?  Is "buffer"
>>       the address (pointer) to the buffer? and "nbytes"
>>       the length of "buffer"?
>
> buffer has integer type, NOT a pointer.  Since it's described as
> "Specifies the buffer from which you want the stored data returned",
> it seems to indicate *WHICH* buffer.  The name "nbytes" strongly
> suggests that it is the length you wish to transfer, in bytes.
>
> In Section 16.6 "Using Cut Buffers", linked to from the pages
> referenced, it explains that there are 8 cut buffers, numbered 0
> through 7.
>
>>    4) does "int" stand for "integer"?
>
> int is a C type, which happens to be a specific integer type.  It
> is not an abbreviation for integer, much in the same way that
> "Ford", "Chrysler", and "Toyota" do not stand for "automobile".
>
>>    5) does "Display" stand for a special variable or a
>>       routine?
>
> Display is a special *TYPE*.  Display * is a pointer to that type.
> It might be implemented as a typedef defined as a struct.  Or perhaps
> as a #define.  Or a union (unlikely, but possible).  You need to
> find the definition to be sure.  It's probably in a header file and
> in the documentation.  Often, such types are supposed to be opaque
> - you should program as though you don't know the implementation
> details (such as field names of a struct and what they mean), as
> they may vary from system to system.
>
> Note that the Display type might itself be a pointer, or
> pointer-to-pointer, etc.  You can't tell this for sure without
> looking at the definition or the documentation.
>
>>    6) why does "*display" have a * in front of it?
>
> The * is part of the type before it:  Display *   .  You are supposed
> to pass a *POINTER* to the type Display (here the variable for this
> is named display), not the whole thing.  You get a pointer to Display
> from somewhere, and pass it to functions to specify which Display
> to use.  (Some programs may handle more than one Display.)
>
>>    7) what does "char" do to "char *XFetchBuffer"?
>
> char * is the return type of XFetchBuffer.  It returns a pointer
> to a character (or in this case, an array of characters).
>
> Incidentally, an * immediately before a type name is an error (at
> least usually - someone will point out an odd exception).
>
> You really need to read up on basic C.  I think you're in over
> your head trying to write C to interface to Perl.
>


Thank you!  I will have to reread several times for it to sink in.

[toc] | [prev] | [next] | [standalone]

#105651

T <T@invalid.invalid> wrote:
> Hi C!

> I am trying to write some inline C code in Perl 6.  Would
> explain to me what is going on in the following two commands:

> References:
>     https://tronche.com/gui/x/xlib/utilities/XStoreBuffer.html
>     https://tronche.com/gui/x/xlib/utilities/XFetchBuffer.html
>     man XStoreBuffer

> int XStoreBuffer(Display *display, char *bytes,
>                   int nbytes, int buffer);

This is a function that returns a value of type 'int',
indicating success (if it's 0) or failure. 'display'
is a pointer to a structure of type ;Display', which
contains information about the connection to the X server
For several reasons structures are often not passed to
functions by value (i.e. passing all the information they
contain) but as a pointer to the location in memory where
the structure can be found.

'buffer' is a variable of type 'pointer to char', i,e.
the address of the memory region where the data you
want to have stored reside. And since that address
doesn't tell the function how many bytes there are to
be stored you also need the 'nbytes' varialbe (of type
'int') to tell the function how many bytes from that
memory location you want to store.

Finally, 'buffer' is another 'int' variable and lets
you tell the X server in which (of up to 8 I think)
buffers you want to store those data.

> char *XFetchBuffer(Display *display,
>                   int *nbytes_return, int buffer);

This function returns a 'pointer to char', which either
is the address where to get the fetched data from or
which is a NULL pointer in case the function failed.
'display' is the same thing as in the othe function call.
'bytes_return' is a pointer to an int. This is used by the
function to return the number of bytes of the data it
returned by storing that number at this location. And
'buffer' is again the number of the buffer.

Here's a very primitive example:

Display *d;                 // must be initialized somewhere!
char mybuf[100];            // must be initialized somewhere!
char *buf;
int len;

XStoreBuffer(d, mybuf, sizeof mybuf, 0);
buf = XFetchBuffer(d, &len, 0);

With the first call you ask the X server to store all the
data form 'mybuf' ('sizeof nybuf' is lust the total size
of that array) in its buffer numbered 0.

The second call should return a pointer to wherever the
X server stored the data. The '&len' argument is the
address of your variable 'len' and the function will
put the length of the buffer the X server has stored
at that address, so after that call it will be the value
of 'len'. And the last argument is again the buffer number.

> Questions:
>     1) what does the * do to the variable?

They don't do anything to the variables, they just
tell the comppiler that they're pointers. If you have

int x;

this defines a variable named 'x' that is of type 'int'
(and has enough memory to hold all the of an 'int'). If you
have

int *pi;

then you get a pointer to a variable of type 'int', i.e.
basically the address of it. You could combine those
two lines as

1 int x = 3;
2 T *pi;
3 px = &i;
4 printf("%d\n", *pi);

In line 3 you assign the address of 'x' (the '&' is the
"address of" operator) to the pointer 'px'. And in line
4 you print out what's stored at that address - the '*'
in this context could be called the 'content of' operator.

If you define a function that acceots an 'int' as its
argument it could be

void foo(int x);

A function that expects a pointer to 'int' would be

void bar(int *pi)

if you want to call it with the address of an existing
variable of type 'int' you'ld do

int x = 13;
bar(&x);

>     2) what does the * do to the subroutine name?

It doesn't do anything with the subroutine name, it merely
says that the function will return a pointer.

>     3) what is "int nbytes, int buffer"?  Is "buffer"
>        the address (pointer) to the buffer? and "nbytes"
>        the length of "buffer"?

'nbytes' is the number of bytes you want to store and
'buffer' is the index of an internal buffer the X server
keeps.

>     4) does "int" stand for "integer"?

It stands for a type that allows to store integers in a
range that depends on the type of machine the program is
running on. The only guarantee is that the range runs
from -32767 to 32767 (but could be quite a bit larger).

>     5) does "Display" stand for a special variable or a
>        routine?

No, it's a structure containing information about which
X server the function should interact with and its capa-
bilities. This could be a server on a different machine
and your program could also be interacting with several X
servers. The details shouldn't be of concern to you. But
if you really want to know what that structure is look
into '/usr/include/X11/Xlibint,h' and search for the
declaration of 'struct _XDisplay' (Display is just an
alias for it).

>     6) why does "*display" have a * in front of it?

Because the function wants a pointer to a 'Display'
structure.

>     7) what does "char" do to "char *XFetchBuffer"?

The 'char *' bit just indicates that the function will
return a pointer to  char, the first char of a set of
'nbytes_return' chars.

One word of warning: as long as you're still struggling
with basic concepts of Cd, as pointers, buffers etc. you
have a big chance of making mistakes that can result in
all kinds of weird errors. And then mixing that with the
very low-level stuff from Xlib is a perfect recipe to
get completely confused. If you use pointers in C you must
be very aware of what you're doing, one mistake and all
kinds of strange things can happen (with a segmentatuon
fault being the most begnin!). I'm not trying to discourage
you but before you start messing around with Xlib (which is
in part that arcane that few people use it directly but
instead some wrapper library) you better have a rather
firm grasp of how C works. And once you start messing
around with Xlib you will need good documentation (not
easy to find, though), not just some random pages from
the internet. "XLIB Programming Manual" by Adrian Nye
is probably your best bet. Perhaps you better check
carefully if what you want to achieve (which I don't
know) can't be done with the graphics package you're
rather likely already using.

                        Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#105689

On 03/09/2017 02:16 AM, Jens Thoms Toerring wrote:
> T <T@invalid.invalid> wrote:
>> Hi C!
>
>> I am trying to write some inline C code in Perl 6.  Would
>> explain to me what is going on in the following two commands:
>
>> References:
>>     https://tronche.com/gui/x/xlib/utilities/XStoreBuffer.html
>>     https://tronche.com/gui/x/xlib/utilities/XFetchBuffer.html
>>     man XStoreBuffer
>
>> int XStoreBuffer(Display *display, char *bytes,
>>                   int nbytes, int buffer);
>
> This is a function that returns a value of type 'int',
> indicating success (if it's 0) or failure. 'display'
> is a pointer to a structure of type ;Display', which
> contains information about the connection to the X server
> For several reasons structures are often not passed to
> functions by value (i.e. passing all the information they
> contain) but as a pointer to the location in memory where
> the structure can be found.
>
> 'buffer' is a variable of type 'pointer to char', i,e.
> the address of the memory region where the data you
> want to have stored reside. And since that address
> doesn't tell the function how many bytes there are to
> be stored you also need the 'nbytes' varialbe (of type
> 'int') to tell the function how many bytes from that
> memory location you want to store.
>
> Finally, 'buffer' is another 'int' variable and lets
> you tell the X server in which (of up to 8 I think)
> buffers you want to store those data.
>
>> char *XFetchBuffer(Display *display,
>>                   int *nbytes_return, int buffer);
>
> This function returns a 'pointer to char', which either
> is the address where to get the fetched data from or
> which is a NULL pointer in case the function failed.
> 'display' is the same thing as in the othe function call.
> 'bytes_return' is a pointer to an int. This is used by the
> function to return the number of bytes of the data it
> returned by storing that number at this location. And
> 'buffer' is again the number of the buffer.
>
> Here's a very primitive example:
>
> Display *d;                 // must be initialized somewhere!
> char mybuf[100];            // must be initialized somewhere!
> char *buf;
> int len;
>
> XStoreBuffer(d, mybuf, sizeof mybuf, 0);
> buf = XFetchBuffer(d, &len, 0);
>
> With the first call you ask the X server to store all the
> data form 'mybuf' ('sizeof nybuf' is lust the total size
> of that array) in its buffer numbered 0.
>
> The second call should return a pointer to wherever the
> X server stored the data. The '&len' argument is the
> address of your variable 'len' and the function will
> put the length of the buffer the X server has stored
> at that address, so after that call it will be the value
> of 'len'. And the last argument is again the buffer number.
>
>> Questions:
>>     1) what does the * do to the variable?
>
> They don't do anything to the variables, they just
> tell the comppiler that they're pointers. If you have
>
> int x;
>
> this defines a variable named 'x' that is of type 'int'
> (and has enough memory to hold all the of an 'int'). If you
> have
>
> int *pi;
>
> then you get a pointer to a variable of type 'int', i.e.
> basically the address of it. You could combine those
> two lines as
>
> 1 int x = 3;
> 2 T *pi;
> 3 px = &i;
> 4 printf("%d\n", *pi);
>
> In line 3 you assign the address of 'x' (the '&' is the
> "address of" operator) to the pointer 'px'. And in line
> 4 you print out what's stored at that address - the '*'
> in this context could be called the 'content of' operator.
>
> If you define a function that acceots an 'int' as its
> argument it could be
>
> void foo(int x);
>
> A function that expects a pointer to 'int' would be
>
> void bar(int *pi)
>
> if you want to call it with the address of an existing
> variable of type 'int' you'ld do
>
> int x = 13;
> bar(&x);
>
>>     2) what does the * do to the subroutine name?
>
> It doesn't do anything with the subroutine name, it merely
> says that the function will return a pointer.
>
>>     3) what is "int nbytes, int buffer"?  Is "buffer"
>>        the address (pointer) to the buffer? and "nbytes"
>>        the length of "buffer"?
>
> 'nbytes' is the number of bytes you want to store and
> 'buffer' is the index of an internal buffer the X server
> keeps.
>
>>     4) does "int" stand for "integer"?
>
> It stands for a type that allows to store integers in a
> range that depends on the type of machine the program is
> running on. The only guarantee is that the range runs
> from -32767 to 32767 (but could be quite a bit larger).
>
>>     5) does "Display" stand for a special variable or a
>>        routine?
>
> No, it's a structure containing information about which
> X server the function should interact with and its capa-
> bilities. This could be a server on a different machine
> and your program could also be interacting with several X
> servers. The details shouldn't be of concern to you. But
> if you really want to know what that structure is look
> into '/usr/include/X11/Xlibint,h' and search for the
> declaration of 'struct _XDisplay' (Display is just an
> alias for it).
>
>>     6) why does "*display" have a * in front of it?
>
> Because the function wants a pointer to a 'Display'
> structure.
>
>>     7) what does "char" do to "char *XFetchBuffer"?
>
> The 'char *' bit just indicates that the function will
> return a pointer to  char, the first char of a set of
> 'nbytes_return' chars.
>
> One word of warning: as long as you're still struggling
> with basic concepts of Cd, as pointers, buffers etc. you
> have a big chance of making mistakes that can result in
> all kinds of weird errors. And then mixing that with the
> very low-level stuff from Xlib is a perfect recipe to
> get completely confused. If you use pointers in C you must
> be very aware of what you're doing, one mistake and all
> kinds of strange things can happen (with a segmentatuon
> fault being the most begnin!). I'm not trying to discourage
> you but before you start messing around with Xlib (which is
> in part that arcane that few people use it directly but
> instead some wrapper library) you better have a rather
> firm grasp of how C works. And once you start messing
> around with Xlib you will need good documentation (not
> easy to find, though), not just some random pages from
> the internet. "XLIB Programming Manual" by Adrian Nye
> is probably your best bet. Perhaps you better check
> carefully if what you want to achieve (which I don't
> know) can't be done with the graphics package you're
> rather likely already using.
>
>                         Regards, Jens
>


Thank you!

[toc] | [prev] | [next] | [standalone]

#105696

On 03/09/2017 02:16 AM, Jens Thoms Toerring wrote:
> "XLIB Programming Manual" by Adrian Nye

I have been using this html version of it.

https://tronche.com/gui/x/xlib/

When I "think" (watch the weasel word) I have found what I
want, I run a man page on the function.  Between the two,
I kind of, almost sort of, understand. Sometimes.

[toc] | [prev] | [next] | [standalone]

#105760

T <T@invalid.invalid> wrote:
> On 03/09/2017 02:16 AM, Jens Thoms Toerring wrote:
> > "XLIB Programming Manual" by Adrian Nye

> I have been using this html version of it.

> https://tronche.com/gui/x/xlib/

That's, as far as I can see, mostlty a collection of man
pages (rather outdated, the use of pre-ANSI C function de-
clarations makes that rather obvious) with very little ex-
tra information. The book I mentioned goes a lot further
into explaining the concepts which I found essential...

                        Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#105781

On 03/10/2017 01:02 PM, Jens Thoms Toerring wrote:
> T <T@invalid.invalid> wrote:
>> On 03/09/2017 02:16 AM, Jens Thoms Toerring wrote:
>>> "XLIB Programming Manual" by Adrian Nye
>
>> I have been using this html version of it.
>
>> https://tronche.com/gui/x/xlib/
>
> That's, as far as I can see, mostlty a collection of man
> pages (rather outdated, the use of pre-ANSI C function de-
> clarations makes that rather obvious) with very little ex-
> tra information. The book I mentioned goes a lot further
> into explaining the concepts which I found essential...
>
>                         Regards, Jens
>


Hmmm.  Thank you!

[toc] | [prev] | [next] | [standalone]

#105652

T <T@invalid.invalid> writes:
<snip>
> int XStoreBuffer(Display *display, char *bytes,
>                  int nbytes, int buffer);
>
> char *XFetchBuffer(Display *display,
>                  int *nbytes_return, int buffer);
>
> Questions:
>    1) what does the * do to the variable?

It does something to the name.  It indicates that the name has a more
complex type that the type sitting just to the left.  C uses an odd
system in which things with types that are derived from the base types
(int, char, float and so on) are declared by decorating the name.

When you see "int ..." you know that the things being declared have
something to do with int (one of C's many integer types) but that's
all.  The details are provided by the stuff around the name.  For
example

   int     x;           // x is an int
   int    *x;           // x is a pointer to int
   int     x[3];        // x is an array of 3 ints
   int    *x[3];        // x is an array of 3 pointers to int
   int   (*x)[3];       // x is a pointer to an array of 3 ints (rare)
   int     x(void);     // x is a function of no arguments
                        // that returns an int
   int    *x(void);     // x is a function of no arguments
                        // that returns a pointer to int
   int   (*x)(void);    // x is a pointer to a function of no arguments
                        // that returns an int.

(Note that, just like in expressions, parentheses are sometimes needed
because the things that go after a name []s and ()s bind more tightly
then * which goes in front.)

Some of the answers here have concentrated on the type, describing "T*"
as a "pointer to T" type.  This fine as far as it goes, but it's less
helpful when

(a) you see mixed declarations like this:

  char c, buf[1000], *bptr = &buf[0];

(b) the declaration is more complex like some of those above.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#105690

On 03/09/2017 02:22 AM, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
> <snip>
>> int XStoreBuffer(Display *display, char *bytes,
>>                  int nbytes, int buffer);
>>
>> char *XFetchBuffer(Display *display,
>>                  int *nbytes_return, int buffer);
>>
>> Questions:
>>    1) what does the * do to the variable?
>
> It does something to the name.  It indicates that the name has a more
> complex type that the type sitting just to the left.  C uses an odd
> system in which things with types that are derived from the base types
> (int, char, float and so on) are declared by decorating the name.
>
> When you see "int ..." you know that the things being declared have
> something to do with int (one of C's many integer types) but that's
> all.  The details are provided by the stuff around the name.  For
> example
>
>    int     x;           // x is an int
>    int    *x;           // x is a pointer to int
>    int     x[3];        // x is an array of 3 ints
>    int    *x[3];        // x is an array of 3 pointers to int
>    int   (*x)[3];       // x is a pointer to an array of 3 ints (rare)
>    int     x(void);     // x is a function of no arguments
>                         // that returns an int
>    int    *x(void);     // x is a function of no arguments
>                         // that returns a pointer to int
>    int   (*x)(void);    // x is a pointer to a function of no arguments
>                         // that returns an int.
>
> (Note that, just like in expressions, parentheses are sometimes needed
> because the things that go after a name []s and ()s bind more tightly
> then * which goes in front.)
>
> Some of the answers here have concentrated on the type, describing "T*"
> as a "pointer to T" type.  This fine as far as it goes, but it's less
> helpful when
>
> (a) you see mixed declarations like this:
>
>   char c, buf[1000], *bptr = &buf[0];
>
> (b) the declaration is more complex like some of those above.
>
> <snip>
>

Thank you!

[toc] | [prev] | [next] | [standalone]

#105655

On Wed, 8 Mar 2017 20:20:03 -0800
T <T@invalid.invalid> wrote:

> Hi C!
> 
> I am trying to write some inline C code in Perl 6.  Would
> explain to me what is going on in the following two commands:
> 
> References:
>     https://tronche.com/gui/x/xlib/utilities/XStoreBuffer.html
>     https://tronche.com/gui/x/xlib/utilities/XFetchBuffer.html
>     man XStoreBuffer
> 
> int XStoreBuffer(Display *display, char *bytes,
>                   int nbytes, int buffer);
> 
> char *XFetchBuffer(Display *display,
>                   int *nbytes_return, int buffer);

Learn C first, questions next... K&R could be a good start.

https://en.wikipedia.org/wiki/The_C_Programming_Language

[toc] | [prev] | [next] | [standalone]

#105692

On 03/09/2017 03:48 AM, GOTHIER Nathan wrote:
> On Wed, 8 Mar 2017 20:20:03 -0800
> T <T@invalid.invalid> wrote:
>
>> Hi C!
>>
>> I am trying to write some inline C code in Perl 6.  Would
>> explain to me what is going on in the following two commands:
>>
>> References:
>>     https://tronche.com/gui/x/xlib/utilities/XStoreBuffer.html
>>     https://tronche.com/gui/x/xlib/utilities/XFetchBuffer.html
>>     man XStoreBuffer
>>
>> int XStoreBuffer(Display *display, char *bytes,
>>                   int nbytes, int buffer);
>>
>> char *XFetchBuffer(Display *display,
>>                   int *nbytes_return, int buffer);
>
> Learn C first, questions next... K&R could be a good start.
>
> https://en.wikipedia.org/wiki/The_C_Programming_Language
>

mumble, mumble.  All I want is to write these two and three other
hooks into XLib.  Then I have enough trouble switching from
Perl 5 to Perl 6.

[toc] | [prev] | [next] | [standalone]

#105724

On 03/09/2017 03:43 PM, T wrote:
> On 03/09/2017 03:48 AM, GOTHIER Nathan wrote:
...
>> Learn C first, questions next... K&R could be a good start.
>>
>> https://en.wikipedia.org/wiki/The_C_Programming_Language
>>
> 
> mumble, mumble.  All I want is to write these two and three other
> hooks into XLib.  Then I have enough trouble switching from
> Perl 5 to Perl 6.

To write those hooks, you need a good understanding of C, a good
understanding of Xlib, and a good understanding of how Perl 6 allows you
to inline C code. Judging from the questions you've asked, you've got a
LOT to learn before you can create those hooks.

[toc] | [prev] | [next] | [standalone]

#105740

On 03/10/2017 07:22 AM, James Kuyper wrote:
> On 03/09/2017 03:43 PM, T wrote:
>> On 03/09/2017 03:48 AM, GOTHIER Nathan wrote:
> ...
>>> Learn C first, questions next... K&R could be a good start.
>>>
>>> https://en.wikipedia.org/wiki/The_C_Programming_Language
>>>
>>
>> mumble, mumble.  All I want is to write these two and three other
>> hooks into XLib.  Then I have enough trouble switching from
>> Perl 5 to Perl 6.
>
> To write those hooks, you need a good understanding of C, a good
> understanding of Xlib, and a good understanding of how Perl 6 allows you
> to inline C code. Judging from the questions you've asked, you've got a
> LOT to learn before you can create those hooks.
>

Duh!

[toc] | [prev] | [next] | [standalone]

#105755

On 03/10/2017 11:47 AM, T wrote:
> On 03/10/2017 07:22 AM, James Kuyper wrote:
>> On 03/09/2017 03:43 PM, T wrote:
>>> On 03/09/2017 03:48 AM, GOTHIER Nathan wrote:
>> ...
>>>> Learn C first, questions next... K&R could be a good start.
>>>>
>>>> https://en.wikipedia.org/wiki/The_C_Programming_Language
>>>>
>>>
>>> mumble, mumble.  All I want is to write these two and three other
>>> hooks into XLib.  Then I have enough trouble switching from
>>> Perl 5 to Perl 6.
>>
>> To write those hooks, you need a good understanding of C, a good
>> understanding of Xlib, and a good understanding of how Perl 6 allows you
>> to inline C code. Judging from the questions you've asked, you've got a
>> LOT to learn before you can create those hooks.
>>
>
> Duh!


“He who asks is a fool for five minutes, but he who does
not ask remains a fool forever.”
     ― Mark Twain

[toc] | [prev] | [next] | [standalone]

#105783

On 03/10/2017 07:22 AM, James Kuyper wrote:
> On 03/09/2017 03:43 PM, T wrote:
>> On 03/09/2017 03:48 AM, GOTHIER Nathan wrote:
> ...
>>> Learn C first, questions next... K&R could be a good start.
>>>
>>> https://en.wikipedia.org/wiki/The_C_Programming_Language
>>>
>>
>> mumble, mumble.  All I want is to write these two and three other
>> hooks into XLib.  Then I have enough trouble switching from
>> Perl 5 to Perl 6.
>
> To write those hooks, you need a good understanding of C, a good
> understanding of Xlib, and a good understanding of how Perl 6 allows you
> to inline C code. Judging from the questions you've asked, you've got a
> LOT to learn before you can create those hooks.

The learning never stops in this field.  I have been off and on
the Perl 6 developers chat server today.  So far, my bumbling
has uncovered two errors in the compiler that they have fixed
for me.  Access to the developers.  Wow, what a resource!
At one point I had to tell them to stop helping me as I had to
learn how to debug this stuff myself.  (I am converting a P5
program to P6.  I find P5's subs to be akin to assembly code
the way they transfer parameters in a single array.)

Thank you all for the crash course in C!

[toc] | [prev] | [next] | [standalone]

#105656

ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>   »int« is the name of an integer type, not an abbreviation
>   for "integer".

Well... int _is_ an abbreviation for integer, it's just that in C, this
abbreviation is used for a specific integer type, to wit, the "natural"
type for signed integers on the system. This is at least 16 bits, these
days usually 32 bits, and may be larger.

Richard

[toc] | [prev] | [next] | [standalone]

#105672

raltbos@xs4all.nl (Richard Bos) writes:
> ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>>   »int« is the name of an integer type, not an abbreviation
>>   for "integer".
>
> Well... int _is_ an abbreviation for integer, it's just that in C, this
> abbreviation is used for a specific integer type, to wit, the "natural"
> type for signed integers on the system. This is at least 16 bits, these
> days usually 32 bits, and may be larger.

The name "int" certainly originated as an abbreviation for "integer",
but in C the name "int" doesn't *mean* "integer".

"int" is a C keyword.  It is also the name of one particular type, and
it's used as part of the syntax for the names of several other types
("unsigned int", "long int", etc.).  The type named "int" is one of a
dozen or so integer types, all of which are distinct.

A similar point of potential confusion: "const" is obviously derived
from the word "constant", but C's "const" keyword means "read-only".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web