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

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

memset

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

Contents

  memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-14 20:32 -0400
    Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-14 20:40 -0400
      Re: memset glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-15 02:11 +0000
        Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-14 22:22 -0400
        Re: memset Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-15 21:07 +0100
    Re: memset Barry Schwarz <schwarzb@dqel.com> - 2014-04-14 21:48 -0700
      Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-15 09:28 -0400
        Re: memset David Brown <david.brown@hesbynett.no> - 2014-04-15 16:07 +0200
          Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-15 21:03 -0400
            Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-15 21:06 -0400
            Re: memset glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-16 01:25 +0000
              Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-15 21:36 -0400
    Re: memset Michael Angelo Ravera <maravera@prodigy.net> - 2014-04-18 13:50 -0700
      Re: memset Kaz Kylheku <kaz@kylheku.com> - 2014-04-18 21:04 +0000
      Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-20 09:16 -0400
        Re: memset Richard <rgrdev_@gmail.com> - 2014-04-20 14:35 +0100
          Re: memset Kaz Kylheku <kaz@kylheku.com> - 2014-04-20 14:10 +0000
            Re: memset gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-21 05:17 +0000
          Re: memset gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-20 15:11 +0000
            Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-22 14:20 -0400
              Re: memset "Osmium" <r124c4u102@comcast.net> - 2014-04-22 14:22 -0500
                Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-22 17:33 -0400
                Re: memset Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-04-25 12:12 +0000
            Re: memset Michael Angelo Ravera <maravera@prodigy.net> - 2014-04-22 15:23 -0700
              Re: memset James Kuyper <jameskuyper@verizon.net> - 2014-04-23 11:39 -0400
                Re: memset "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-24 21:19 -0400

Page 1 of 2  [1] 2  Next page →

#42927 — memset

    I think alot of my problem is not understanding what a function is 
asking for when it's asking for a pointer. If it's asking for a pointer is 
it wanting what the pointer is pointing too. memset for example.

void *memset (void *s, int c, size_t n);

that first parameter. Is it want a pointer to something or to be passed what 
the pointer is pointing to. For example.

int *p;

memset(p,0,sizeof(int));
or memset(&p,0,sizeof(int));

Is such a thing as a function that wants this?

function (int &a, short &b);

If something is defined like that would you just pass the pointer?

Bill

[toc] | [next] | [standalone]

#42929

    Hum. Is this pass by reference? I want C not C++.

Bill

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

#42942

Bill Cunningham <nospam@nspam.invalid> wrote:

>    Hum. Is this pass by reference? I want C not C++.

C is pass by value (or call by value). If you want a function
call to be able to change something, you pass a pointer to
the something.

But also you often (usually) pass a pointer when you are 
passing an array or structure. Before ANSI C, you couldn't pass
structures directly, only through pointers. ANSI allows it, but
it isn't used all that often.

-- glen

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

#42943

glen herrmannsfeldt wrote:
> Bill Cunningham <nospam@nspam.invalid> wrote:
>
>>    Hum. Is this pass by reference? I want C not C++.
>
> C is pass by value (or call by value). If you want a function
> call to be able to change something, you pass a pointer to
> the something.
>
> But also you often (usually) pass a pointer when you are
> passing an array or structure. Before ANSI C, you couldn't pass
> structures directly, only through pointers. ANSI allows it, but
> it isn't used all that often.
>
> -- glen

In your ś2 I believe I understand that. But my parameters if I want an array 
is usually define as...

int func(int a[]){}

Then that way the paramter tells you you are wanting to pass an array. It's 
more explicit than...

int func (int *a){}

Your first ś C is pass by value... I may just be beginning to realize what 
that might entail. Like the freeaddrinfo function it wants a pointer. But 
you don't pass &value to it. you actually pass the pointer

freeaddrinfo(value);
not freeaddrinfo(&value);

Because the second example is saying you are passing what a pointer is 
pointing to. Does this make any sense?

Bill

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

#42993

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
<snip>
> But also you often (usually) pass a pointer when you are 
> passing an array or structure. Before ANSI C, you couldn't pass
> structures directly, only through pointers.

It was allowed before ANSI C.  However, there is (as far as I know) no
official definition of C with structure passing/returning/assigning
(they all happened at the same time) that predates ANSI C.  In those
days, C was, by and large, what the Unix compiler accepted.

The C described in K&R does not have these things, but the book
explicitly flags them up as coming in a future version.  Sadly, I
remember the release and the joy it brought to all who compiled with it.

<snip>
-- 
Ben.

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

#42947

On Mon, 14 Apr 2014 20:32:11 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>    I think alot of my problem is not understanding what a function is 
>asking for when it's asking for a pointer. If it's asking for a pointer is 
>it wanting what the pointer is pointing too. memset for example.

If the function asks for a pointer value, the corresponding argument
must be a pointer value.  If the function wants to access the value
pointed to, it is the function's responsibility to dereference the
pointer value.  This is what happens in the vast majority of cases,
including your current favorite memset.

On the other hand, there are functions like free and realloc which ask
for a pointer value and may never dereference it.

For standard library functions, you shouldn't care.  The function
description tells you what the parameters are used for and your only
concern should be to insure the argument you pass is suitable for that
use.

>
>void *memset (void *s, int c, size_t n);
>
>that first parameter. Is it want a pointer to something or to be passed what 
>the pointer is pointing to. For example.

Reason it out.  Does the compiler know what a pointer to void points
to?  Does memset?  Do either care?  Have you seen any documentation
anywhere that implies the compiler can or does change a pointer type
argument from an address to the data at that address?

>int *p;

int i;
p = &i;

>memset(p,0,sizeof(int));

You should be able to explain why this invokes undefined behavior
without the two statements I added.

It should not be a surprise that you can achieve the same effect with
    memset(&i, 0, sizeof i);
eliminating both the need for p and dependency in the code on the type
of p or i.

>or memset(&p,0,sizeof(int));

     memset(&p, 0, sizeof(int*));

You should be able to explain why I made the change and why your code
could potentially invoke undefined behavior depending on certain
system characteristics.

>Is such a thing as a function that wants this?

What you coded - no.  What I coded is legal but 
     p = NULL;
accomplishes the same thing much more simply.  On the other hand, if p
were a pointer to structure, then
    memset(p, 0, sizeof *p);
could be potentially useful but note the lack of an ampersand.

>function (int &a, short &b);

>If something is defined like that would you just pass the pointer?

You would pass two pointer values, either by specify the names of
pointer objects or by using the & operand on suitable objects.  What
other option do you think would work?

-- 
Remove del for email

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

#42960

Bill Cunningham wrote:
> Barry Schwarz wrote:
>> On Mon, 14 Apr 2014 20:32:11 -0400, "Bill Cunningham"
> [snip]
>
> I don't know. The only thing I know is to jump into code dealing with
> pointers and go from there. If I have problems come here and try to
> figure it out. As is said, "C wears well as one's experience with
> it..." and so on. But this seems to be a common problem that pointers
> cause problems with a lot of people. I guess I'll have to go one step
> at a time and when I get burned out take a break.
>
> Bill

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

#42962

On 15/04/14 15:28, Bill Cunningham wrote:
> Bill Cunningham wrote:
>> Barry Schwarz wrote:
>>> On Mon, 14 Apr 2014 20:32:11 -0400, "Bill Cunningham"
>> [snip]
>>
>> I don't know. The only thing I know is to jump into code dealing with
>> pointers and go from there. If I have problems come here and try to
>> figure it out. As is said, "C wears well as one's experience with
>> it..." and so on. But this seems to be a common problem that pointers
>> cause problems with a lot of people. I guess I'll have to go one step
>> at a time and when I get burned out take a break.
>>
>> Bill
> 
> 

You are trying to learn about C pointers by guessing, randomly snipping
sections of sample code, and trial-and-error, and then expecting other
people to spoon-feed you fixes for the resulting mess.  People in this
group have been extraordinarily patient with you, but there is no
possibility that you will ever learn C properly in this way.

Buy a book on C for beginners, and study it /properly/.  I don't know
what your native language is (by the grammar in your posts, I'm guessing
it is not English), but you might be lucky and get one that is easy
enough for you to follow.

When you have some of the basics, and have more questions than are
answered in the book, many people here will be willing to help answer you.

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

#42997

David Brown wrote:
> On 15/04/14 15:28, Bill Cunningham wrote:
>> Bill Cunningham wrote:
>>> Barry Schwarz wrote:
>>>> On Mon, 14 Apr 2014 20:32:11 -0400, "Bill Cunningham"
>>> [snip]
>>>
>>> I don't know. The only thing I know is to jump into code dealing
>>> with pointers and go from there. If I have problems come here and
>>> try to figure it out. As is said, "C wears well as one's experience
>>> with it..." and so on. But this seems to be a common problem that
>>> pointers cause problems with a lot of people. I guess I'll have to
>>> go one step at a time and when I get burned out take a break.
>>>
>>> Bill
>>
>>
>
> You are trying to learn about C pointers by guessing, randomly
> snipping sections of sample code, and trial-and-error, and then
> expecting other people to spoon-feed you fixes for the resulting
> mess.  People in this group have been extraordinarily patient with
> you, but there is no possibility that you will ever learn C properly
> in this way.
>
> Buy a book on C for beginners, and study it /properly/.  I don't know
> what your native language is (by the grammar in your posts, I'm
> guessing it is not English), but you might be lucky and get one that
> is easy enough for you to follow.
>
> When you have some of the basics, and have more questions than are
> answered in the book, many people here will be willing to help answer
> you.

I do not know why someone would want to help someone who knew what they were 
doing. That makes no sense at all to me. Or why they would want or need help 
if they knew C?

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

#42998

Bill Cunningham wrote:

> I do not know why someone would want to help someone who knew what
> they were doing. That makes no sense at all to me. Or why they would
> want or need help if they knew C?

So in order to get help one must not need help then. I see.

Rationality is not a popular trait in clc.

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

#42999

Bill Cunningham <nospam@nspam.invalid> wrote:
> David Brown wrote:

(snip)

>> You are trying to learn about C pointers by guessing, randomly
>> snipping sections of sample code, and trial-and-error, and then
>> expecting other people to spoon-feed you fixes for the resulting
>> mess.  People in this group have been extraordinarily patient with
>> you, but there is no possibility that you will ever learn C properly
>> in this way.

>> Buy a book on C for beginners, and study it /properly/.  I don't know
>> what your native language is (by the grammar in your posts, I'm
>> guessing it is not English), but you might be lucky and get one that
>> is easy enough for you to follow.

>> When you have some of the basics, and have more questions than are
>> answered in the book, many people here will be willing to help answer
>> you.
 
> I do not know why someone would want to help someone who knew what 
> they were doing. That makes no sense at all to me. Or why they 
> would want or need help if they knew C?

Well, some of the discussion here is on the very fine points in the
language, some might never come up in real programs.  

You will still get help here, but you are expected to do some of
the help yourself.  OK, since it is baseball season and I have an
mlb.com gameday window open, you wouldn't send your little-league
kid out to batting practice with an MLB pitcher. For one, he wouldn't
learn anything, and for another it could be very dangerous if
he got hit by a pitch.  

On the other hand, even the best programmers make dumb mistakes
once in a while. 

In my early assembler programs, I wasn't so sure what I was doing,
but tried some things and learned how they worked. I mostly did it
from IBM manuals, and not much asking, but there was some guessing.

You should find some good books, including explanations on how
and when to use pointers in C. If you can't understand the
explanation, ask here.

-- glen

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

#43000

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in > You should find some 
good books, including explanations on how
> and when to use pointers in C. If you can't understand the
> explanation, ask here.

    I have read C book after C book. And learned alittle. I don't know if 
I'm just one of those people that learns hands on or what. It seems like 
that's the way I learn.

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

#43097

On Monday, April 14, 2014 5:32:11 PM UTC-7, Bill Cunningham wrote:
> I think alot of my problem is not understanding what a function is 
> asking for when it's asking for a pointer. If it's asking for a pointer is 
> it wanting what the pointer is pointing too. memset for example.
> 
> void *memset (void *s, int c, size_t n);
> 
> that first parameter. Is it want a pointer to something or to be passed what 
> the pointer is pointing to. For example.
> 
> int *p;
> memset(p,0,sizeof(int));
>
> or memset(&p,0,sizeof(int));
> 
> Is such a thing as a function that wants this?
> function (int &a, short &b);
> 
> If something is defined like that would you just pass the pointer?


OK. Your fundamental lack of understanding is that of data representation. Programming in C is designed for people who understand data representation and not for people who don't.

What's a pointer? A pointer is a value that represents where something is stored.

For most (it is intended and they are working on "all") data items in C, there is a way to obtain a pointer to it. This is often referred to as "dereferencing". For most pointers, there is a way to obtain the data (or first item of data) to which it points, if such a reference would refer to something in the representation (otherwise you will have some kind of a problem -- ranging from "that's not what I meant" on up to "halt and catch fire".)

So, let's look at memset: The first argument is a pointer to the beginning of the of the area of memory that you want to set to the particular value. 
This area may represent an array, a structure, a single data item ("scalar"), or a memory map of some device. The function doesn't know or really care all that much. If you tell it to blast '*'s to the memory map of a printer and your program has proper access to it, you will probably get a bunch of '*'s on the paper (or whatever the '*'s represent to the printer). The function memset just puts however many copies you say of whatever character you say in an area of memory that you say. It doesn't know what it is doing or whether it is doing what you want. It is very much like a screwdriver -- really good for tightening or removing screws, usable for drilling holes, can be made to pry things off of each other, really bad for jamming into your eye.

So, the trick in getting memset to do what you want (like putting spaces into a character array where you are going to place a name of something, or putting '*'s into any eye catcher string), is to obtain a pointer to the beginning of the area, determining to what value you want to set everything, and obtaining a byte count for the thing that you want to set.

Usually, you can obtain a pointer to the beginning of the representation of something simply dereferencing it with the "&" operator and you can obtain the size of the representation of the that thing by using either "sizeof" or, with some more complicated things, by using "offsetof". But, you need to supply sizeof with the representation of the entire thing that you want to set. In some cases, you will use offsetof (thing, last_variable_thing[number_of_last_variable_things]).

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

#43100

On 2014-04-18, Michael Angelo Ravera <maravera@prodigy.net> wrote:
> On Monday, April 14, 2014 5:32:11 PM UTC-7, Bill Cunningham wrote:
>
> OK. Your fundamental lack of understanding ...

... is a trolling project that is over a decade long, and counting.

Here is post from January 2003:

https://groups.google.com/forum/#!original/comp.lang.c/XCNaLai1vmk/kccdq6h7B0kJ

The news article posting personality calling itself "Bill Cunningham" does not
retain a single fucking new shred of knowledge ever thrown at it.

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

#43175

Michael Angelo Ravera wrote:

> OK. Your fundamental lack of understanding is that of data
> representation. Programming in C is designed for people who
> understand data representation and not for people who don't.
>
> What's a pointer? A pointer is a value that represents where
> something is stored.
>
> For most (it is intended and they are working on "all") data items in
> C, there is a way to obtain a pointer to it. This is often referred
> to as "dereferencing". For most pointers, there is a way to obtain
> the data (or first item of data) to which it points, if such a
> reference would refer to something in the representation (otherwise
> you will have some kind of a problem -- ranging from "that's not what
> I meant" on up to "halt and catch fire".)
>
> So, let's look at memset: The first argument is a pointer to the
> beginning of the of the area of memory that you want to set to the
> particular value.
> This area may represent an array, a structure, a single data item
> ("scalar"), or a memory map of some device. The function doesn't know
> or really care all that much. If you tell it to blast '*'s to the
> memory map of a printer and your program has proper access to it, you
> will probably get a bunch of '*'s on the paper (or whatever the '*'s
> represent to the printer). The function memset just puts however many
> copies you say of whatever character you say in an area of memory
> that you say. It doesn't know what it is doing or whether it is doing
> what you want. It is very much like a screwdriver -- really good for
> tightening or removing screws, usable for drilling holes, can be made
> to pry things off of each other, really bad for jamming into your
> eye.
>
> So, the trick in getting memset to do what you want (like putting
> spaces into a character array where you are going to place a name of
> something, or putting '*'s into any eye catcher string), is to obtain
> a pointer to the beginning of the area, determining to what value you
> want to set everything, and obtaining a byte count for the thing that
> you want to set.
>
> Usually, you can obtain a pointer to the beginning of the
> representation of something simply dereferencing it with the "&"
> operator and you can obtain the size of the representation of the
> that thing by using either "sizeof" or, with some more complicated
> things, by using "offsetof". But, you need to supply sizeof with the
> representation of the entire thing that you want to set. In some
> cases, you will use offsetof (thing,
> last_variable_thing[number_of_last_variable_things]).

    Thanks Michael but I will have to admit; a lot of this is a little over 
my head right now. There's just something about these pointers. But I guess 
that's a common problem with persons who use C. I am a hobbyist. I have been 
trying to learn C on and off for a long time. I take a break for a while and 
I am finding learn as you go seems to slowly work. I appreciate any help 
though. It doesn't go unnoticed.

Bill

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

#43176

"Bill Cunningham" <nospam@nspam.invalid> writes:

> Michael Angelo Ravera wrote:
>
>> OK. Your fundamental lack of understanding is that of data
>> representation. Programming in C is designed for people who
>> understand data representation and not for people who don't.
>>
>> What's a pointer? A pointer is a value that represents where
>> something is stored.

You have to say "represents" dont you? Why not just say it points to
where the data is? Sheesh.

>>
>> For most (it is intended and they are working on "all") data items in
>> C, there is a way to obtain a pointer to it. This is often referred
>> to as "dereferencing". For most pointers, there is a way to obtain

NO it isnt. It's called referencing. Dereferencing is obtaining the data
from the location pointed to by the pointer.

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

When being surly and elite and putting people down it's frequently better
not to get wrapped up in your own twaddle.

>> the data (or first item of data) to which it points, if such a
>> reference would refer to something in the representation (otherwise
>> you will have some kind of a problem -- ranging from "that's not what
>> I meant" on up to "halt and catch fire".)
>>
>> So, let's look at memset: The first argument is a pointer to the
>> beginning of the of the area of memory that you want to set to the
>> particular value.
>> This area may represent an array, a structure, a single data item
>> ("scalar"), or a memory map of some device. The function doesn't know
>> or really care all that much. If you tell it to blast '*'s to the
>> memory map of a printer and your program has proper access to it, you
>> will probably get a bunch of '*'s on the paper (or whatever the '*'s
>> represent to the printer). The function memset just puts however many
>> copies you say of whatever character you say in an area of memory
>> that you say. It doesn't know what it is doing or whether it is doing
>> what you want. It is very much like a screwdriver -- really good for
>> tightening or removing screws, usable for drilling holes, can be made
>> to pry things off of each other, really bad for jamming into your
>> eye.
>>
>> So, the trick in getting memset to do what you want (like putting
>> spaces into a character array where you are going to place a name of
>> something, or putting '*'s into any eye catcher string), is to obtain
>> a pointer to the beginning of the area, determining to what value you
>> want to set everything, and obtaining a byte count for the thing that
>> you want to set.
>>
>> Usually, you can obtain a pointer to the beginning of the
>> representation of something simply dereferencing it with the "&"
>> operator and you can obtain the size of the representation of the
>> that thing by using either "sizeof" or, with some more complicated
>> things, by using "offsetof". But, you need to supply sizeof with the
>> representation of the entire thing that you want to set. In some
>> cases, you will use offsetof (thing,
>> last_variable_thing[number_of_last_variable_things]).
>
>     Thanks Michael but I will have to admit; a lot of this is a little over 
> my head right now. There's just something about these pointers. But I guess 
> that's a common problem with persons who use C. I am a hobbyist. I have been 
> trying to learn C on and off for a long time. I take a break for a while and 
> I am finding learn as you go seems to slowly work. I appreciate any help 
> though. It doesn't go unnoticed.
>
> Bill
>

No. It doesn't ... lol.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

#43181

On 2014-04-20, Richard <rgrdev_@gmail.com> wrote:
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>
>> Michael Angelo Ravera wrote:
>>
>>> OK. Your fundamental lack of understanding is that of data
>>> representation. Programming in C is designed for people who
>>> understand data representation and not for people who don't.
>>>
>>> What's a pointer? A pointer is a value that represents where
>>> something is stored.
>
> You have to say "represents" dont you? Why not just say it points to
> where the data is? Sheesh.

Because then he would be dropping less of a clue that he's not a genuine
retard.

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

#43212

In article <20140420070858.262@kylheku.com>,
Kaz Kylheku  <kaz@kylheku.com> wrote:
>On 2014-04-20, Richard <rgrdev_@gmail.com> wrote:
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>
>>> Michael Angelo Ravera wrote:
>>>
>>>> OK. Your fundamental lack of understanding is that of data
>>>> representation. Programming in C is designed for people who
>>>> understand data representation and not for people who don't.
>>>>
>>>> What's a pointer? A pointer is a value that represents where
>>>> something is stored.
>>
>> You have to say "represents" dont you? Why not just say it points to
>> where the data is? Sheesh.
>
>Because then he would be dropping less of a clue that he's not a genuine
>retard.

I'm still trying to parse this last sentence.  What does it mean?

Help me out here, please...

-- 
"I heard somebody say, 'Where's Nelson Mandela?' Well, 
Mandela's dead. Because Saddam killed all the Mandelas." 

George W. Bush, on the former South African president who 
is still very much alive, Sept. 20, 2007

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

#43183

In article <87ppkcrune.fsf@gmail.com>, Richard  <rgrdev_@gmail.com> wrote:
...
>>     Thanks Michael but I will have to admit; a lot of this is a little over 
>> my head right now. There's just something about these pointers. But I guess 
>> that's a common problem with persons who use C. I am a hobbyist. I have been 
>> trying to learn C on and off for a long time. I take a break for a while and 
>> I am finding learn as you go seems to slowly work. I appreciate any help 
>> though. It doesn't go unnoticed.
>>
>> Bill
>>
>
>No. It doesn't ... lol.

What I love is the implication in Bill's posts (the one above and others
over the years) that there is some big do-ha to learning C.  For crying out
loud, it's a programming language; it's not like it's a spoken foreign
language (which really does take years of study and effort to learn).  In
the real world, people are expected to pick up programming languages and
start using them in a matter of days.

BTW, welcome "Michael Angelo Ravera" to the small group of twisted nuts who
post in both CLC and RGB.  There's a lot of similarity between the two
groups - both arenas (C and Bridge) offer a lot of opportunities for
cliquishness and snarkiness.  As far as I know, there are 3 in the club at
present (me, Martin Ambuhl, and now you).

P.S.  I'm pretty sure that "Bill Cunningham" is one of the regs in
disguise.  The reasons for this should be obvious.

-- 
Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?
~ Epicurus

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

#43326

Kenny McCormack wrote:

[snip]

> What I love is the implication in Bill's posts (the one above and
> others over the years) that there is some big do-ha to learning C.

    Try working with not well documented functions. Or ones that are new to 
you in some cases. A non standard C function getaddrinfo() gave me fits when 
I first started working with it. And a lot of it was not fully understanding 
not so much C syntax as what to do with the function.

    I do not consider myself a regular poster here on clc but a regular 
lurker. And I do post from time to time, though I've been here a while.

Bill

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web