function sprintf

[Michele]

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?
Thanks
michele

[Leor Zolman]

On Thu, 1 Apr 2004 21:31:39 +0200, "Michele" <mi********@libero.it> wrote:

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?
Thanks
michele
Have you got a library reference book handy? If not, how about a browser?
You can get all the info you need on library facilities online. I like the
Dinkumware site:
http://dinkumware.com/manuals/reader.aspx?lib=cpp
(It's the "C++" lib, but that includes the C headers. You'll find sprintf
in sdio.h)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Malcolm]

"Michele" <mi********@libero.it> wrote in message

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?

You need to look up the function. sprintf() formats characters to a string.
If you've used C at all you'll be familiar with the printf() function.
sprintf() is very similar, but characters are stored instead of being passed
to the output.

buf is the destination string. It must be a char * pointing to enough memory
to hold the output.
"%20g" is the format string. %g tells the computer to print a floating-point
vlaue, and the 20 is the field width specifier.
*(liftPtr++) means take what liftPtr points to, here a floating-point
number, and then increment the pointer as a size effect. Your are obviously
looking at some code which is printing out a list of floating point numbers.

[Leor Zolman]

On Thu, 1 Apr 2004 21:31:39 +0200, "Michele" <mi********@libero.it> wrote:

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do?
Oh sorry, I did mean to help you with the pointer expression part.

This code implies that liftPtr is a pointer to float or double (presumably
a pointer to somewhere within an array of them.) Let's just call it double,
since there isn't much to go on (I'm assuming it is a floating point type
because of the %g format conversion being used to display a value).

The value of the expression (liftPtr++) is the present ("old") value of
that pointer; the indirection operator (*) is applied to that value,
yielding the value of the double that the pointer goes into that statement
pointing to.

Before the next line of code executes (I'm simplifying here), the value of
liftPtr will have been incremented to point to the /next/ double in
sequence. That's what the ++ does, and its position on the right of its
operand ("postfix" notation) is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

Make sense?
-leor
Thanks
michele

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Neil Cerutti]

In article <c4**********@newsread.albacom.net>, Michele wrote:

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean?

It means it's time to read some documentation. ;-)

--
Neil Cerutti
"Captain, every day I grow more and more convinced that the
wisest and the best is to fix your eyes on the good and the beautiful."
"You're some guy McKonan." -_The Phantom Planet_

[pete]

Leor Zolman wrote:

On Thu, 1 Apr 2004 21:31:39 +0200,
"Michele" <mi********@libero.it> wrote:

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean?

The value of the expression (liftPtr++) is the present
("old") value of that pointer;
the indirection operator (*) is applied to that value,
yielding the value of the double that the pointer goes into that
statement pointing to.

Before the next line of code executes (I'm simplifying here),'
the value of liftPtr will have been incremented to point to
the /next/ double in sequence. That's what the ++ does, and its
position on the right of its operand ("postfix" notation)
is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

Make sense?

I want to emphasize that there is no order as to
whether the evaluation or the increment takes place first.
By putting the word "delays" in quotes, you suggest that
you are aware of that, but it might be too subtle for OP.

--
pete

[Leor Zolman]

On Fri, 02 Apr 2004 08:51:11 GMT, pete <pf*****@mindspring.com> wrote:

Leor Zolman wrote:

On Thu, 1 Apr 2004 21:31:39 +0200,
"Michele" <mi********@libero.it> wrote:

>I have a code line like this:
>sprintf(buf, "%20g",*(liftPtr++))
>what does it mean?

The value of the expression (liftPtr++) is the present
("old") value of that pointer;
the indirection operator (*) is applied to that value,
yielding the value of the double that the pointer goes into that
statement pointing to.

Before the next line of code executes (I'm simplifying here),'
the value of liftPtr will have been incremented to point to
the /next/ double in sequence. That's what the ++ does, and its
position on the right of its operand ("postfix" notation)
is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

Make sense?

I want to emphasize that there is no order as to
whether the evaluation or the increment takes place first.
By putting the word "delays" in quotes, you suggest that
you are aware of that, but it might be too subtle for OP.

Right, I just didn't think the OP was in particular need of that level of
detail at this point in her learning curve. But note that I was careful in
my wording to say "the old value has been sampled", rather than stating
there was an order between the increment and the indirection operation (he
/can/ be taught.) I don't see how the increment could possibly take place
/before/ the old value had ever been "sampled". My intent was to prevent
the meaning from being misconstrued ;-)
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Bliss]

Michele dropped $0.03 in the slot and wrote:

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean? And what does the function sprintf do? It is like printf() but outputs to a string.
It means find the float (or double) pointed to by liftPtr and
put its text representation in the string pointed to by buf and then
add one to the pointer liftPtr.

Roger.

[Michele]

I'm sorry, maybe I'm too lazy...
thanks
michele

"Neil Cerutti" <ho*****@yahoo.com> ha scritto nel messaggio
news:c4*************@ID-60390.news.uni-berlin.de...

In article <c4**********@newsread.albacom.net>, Michele wrote:

I have a code line like this:
sprintf(buf, "%20g",*(liftPtr++))
what does it mean?

It means it's time to read some documentation. ;-)

--
Neil Cerutti
"Captain, every day I grow more and more convinced that the
wisest and the best is to fix your eyes on the good and the beautiful."
"You're some guy McKonan." -_The Phantom Planet_

[Chris Torek]

(on the postfix "++" operator)

In article <news:72********************************@4ax.com >
Leor Zolman <le**@bdsoft.com> writes:

... I don't see how the increment could possibly take place
/before/ the old value had ever been "sampled".

Some of this depends on what one means by "sampled", but consider
the following concrete expansion of:

i = j++;

on a machine with i and j in registers:

inc reg_holding_j # j = j + 1
sub reg_holding_j, 1, reg_holding_i # i = j - 1

Here, even though the "inc" happens "last" in principle (because i
has to get set to the old value of j), the compiler has for some
reason incremented j first, then subtracted 1 from the result to
re-compute the old value.

(Of course, the original example was more like "*p++", which probably
would have added 8 to p on a byte-oriented machine -- but the above
still works if one changes all the "1"s to "8"s. It is legal, just
peculiar, to do the increment first. There are some odd instruction
sets that encourage this kind of odd machine code, though.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Leor Zolman]

On Fri, 2 Apr 2004 19:50:09 +0200, "Michele" <mi********@libero.it> wrote:

I'm sorry, maybe I'm too lazy...
thanks
michele
I think it takes less work to look something up, once you have the book
handy or the bookmark in place in your browser favorites, than it does to
post a question to a newsgroup. So you can indulge your laziness /and/ get
the answer quicker. What's not to like?
-leor

"Neil Cerutti" <ho*****@yahoo.com> ha scritto nel messaggio
news:c4*************@ID-60390.news.uni-berlin.de...

In article <c4**********@newsread.albacom.net>, Michele wrote:

> I have a code line like this:
> sprintf(buf, "%20g",*(liftPtr++))
> what does it mean?

It means it's time to read some documentation. ;-)

--
Neil Cerutti
"Captain, every day I grow more and more convinced that the
wisest and the best is to fix your eyes on the good and the beautiful."
"You're some guy McKonan." -_The Phantom Planet_

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On 2 Apr 2004 17:21:11 GMT, Chris Torek <no****@torek.net> wrote:

(on the postfix "++" operator)

In article <news:72********************************@4ax.com >
Leor Zolman <le**@bdsoft.com> writes:

... I don't see how the increment could possibly take place
/before/ the old value had ever been "sampled".

Some of this depends on what one means by "sampled", but consider
the following concrete expansion of:

i = j++;

on a machine with i and j in registers:

inc reg_holding_j # j = j + 1
sub reg_holding_j, 1, reg_holding_i # i = j - 1

Here, even though the "inc" happens "last" in principle (because i
has to get set to the old value of j), the compiler has for some
reason incremented j first, then subtracted 1 from the result to
re-compute the old value.

(Of course, the original example was more like "*p++", which probably
would have added 8 to p on a byte-oriented machine -- but the above
still works if one changes all the "1"s to "8"s. It is legal, just
peculiar, to do the increment first. There are some odd instruction
sets that encourage this kind of odd machine code, though.)

I was just asking for it, wasn't I? ;-)

Seriously, though, is it really the general consensus of the group that
this ordering issue should be required as part of the answer to /any/ level
of question on the behavior of post-increment expressions? I really, really
didn't want to go into the full-blown explanation, because I made the
judgment that Michele would neither have needed nor wanted to know the
full, gory details. If the question had been phrased at a different level,
such as "I know what the basic purpose is, but what are the /real/ ordering
requirements here?" then fine. But when someone asks "What does it mean?"
and points to a line of code such the one shown, I think that level of
detail is just plain inappropriate. I recognize I may be in the minority
here. Perhaps Michele would be willing to provide me with a reality check?
Thanks,
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leor Zolman wrote:

[snip]
| I don't see how the increment could possibly take place
| /before/ the old value had ever been "sampled".
Leor, consider a hypothetical compiler on a machine that permits
indexing. The generated code might look like

~ inc liftPtr
~ ld temp,(liftPtr - 1)

Or, in terms of a real processor (still hypothetical compiler though),
consider the following Z80 instructions

~ inc ix
~ ld a,(ix-1)

where ix contains the value of liftPtr, and a will contain the result of
~ *(liftPtr++)

- --

Lew Pitcher, IT Consultant, Enterprise Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFAbav0agVFX4UWr64RAqxrAKC28vs1rRlDXKLuyzrjy+ VtYTppZACgrusS
dtPCl/HffSc7gLBGRaHOjQ0=
=cdcR
-----END PGP SIGNATURE-----

[Alan Balmer]

On Fri, 02 Apr 2004 18:18:19 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Seriously, though, is it really the general consensus of the group that
this ordering issue should be required as part of the answer to /any/ level
of question on the behavior of post-increment expressions?

Not for me. I would argue that if this fact makes any difference to
your program, the program probably needs some attention.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Richard Heathfield]

Leor Zolman wrote:

Seriously, though, is it really the general consensus of the group that
this ordering issue should be required as part of the answer to /any/
level of question on the behavior of post-increment expressions?

Not on my account. It's a tricky line to walk. Explain too much and you get
typist's cramp. Explain too little and people correct you. (Sigh.)

On the other hand, Chris Torek is always good for a read, so don't let it
get you down. :-)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Leor Zolman]

On Fri, 2 Apr 2004 20:27:58 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

Leor Zolman wrote:

Seriously, though, is it really the general consensus of the group that
this ordering issue should be required as part of the answer to /any/
level of question on the behavior of post-increment expressions?

Not on my account. It's a tricky line to walk. Explain too much and you get
typist's cramp. Explain too little and people correct you. (Sigh.)

On the other hand, Chris Torek is always good for a read, so don't let it
get you down. :-)

Oh, it didn't get me "down" at all! (in fact, I get a buzz from seeing
assembly code, mostly because it makes me so happy to not have to be coding
in it any more.)

I just tried so /hard/ to write my explanation of *ptr++ in such a way as
to give the OP the info I thought was most important, without triggering
the nit picking, and I didn't quite pull it off. Looking back at what I
wrote, I realize now I could have re-phrased the offending part in a
temporally-neutral manner, which would probably have been good enough. So
instead of:

That's what the ++ does, and its position on the right of its
operand ("postfix" notation) is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

I might have said:

That's what the ++ does, and its position on the right of its operand
("postfix" notation) is what specifies that the "old" value of liftPtr is
used as the operand to '*'.

Better?
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Richard Heathfield]

Leor Zolman wrote:

I just tried so /hard/ to write my explanation of *ptr++ in such a way as
to give the OP the info I thought was most important, without triggering
the nit picking, and I didn't quite pull it off.
Here's your badge. Here's your locker key. Toilets are down the hall, on the
left. Fire escape is out the back. You can use that coffee machine over
there. (This one here is private, I'm afraid. I get through a lot of
coffee, ever since the Incident Involving An Assertion Failure.)

Welcome to comp.lang.c.
Looking back at what I
wrote, I realize now I could have re-phrased the offending part in a
temporally-neutral manner, which would probably have been good enough. So
instead of:

That's what the ++ does, and its position on the right of its
operand ("postfix" notation) is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

I might have said:

That's what the ++ does, and its position on the right of its operand
("postfix" notation) is what specifies that the "old" value of liftPtr is
used as the operand to '*'.

Better?

Yes, I think it's much improved. Specifically, it doesn't unwittingly assume
a particular implementation.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Neil Cerutti]

In article <v8********************************@4ax.com>, Leor
Zolman wrote:

I might have said:

That's what the ++ does, and its position on the right of its operand
("postfix" notation) is what specifies that the "old" value of liftPtr is
used as the operand to '*'.

Better?

I find it's clearest to speak about the value of operators with
side effects in terms of what they evaluate to, i.e., ptr++
evaluates to ptr, while ++ptr evaluates to ptr+1, even though
they have the same side effect.

--
Neil Cerutti
"Captain, every day I grow more and more convinced that the
wisest and the best is to fix your eyes on the good and the beautiful."
"You're some guy McKonan." -_The Phantom Planet_

[Leor Zolman]

On 3 Apr 2004 15:21:08 GMT, Neil Cerutti <ho*****@yahoo.com> wrote:

In article <v8********************************@4ax.com>, Leor
Zolman wrote:

I might have said:

That's what the ++ does, and its position on the right of its operand
("postfix" notation) is what specifies that the "old" value of liftPtr is
used as the operand to '*'.

Better?

I find it's clearest to speak about the value of operators with
side effects in terms of what they evaluate to, i.e., ptr++
evaluates to ptr, while ++ptr evaluates to ptr+1, even though
they have the same side effect.

That sounds good. I have more trouble with terminology than anything else;
perhaps it is because English was my third language, I don't know...
Thanks,
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Sat, 3 Apr 2004 06:47:45 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

Leor Zolman wrote:

I just tried so /hard/ to write my explanation of *ptr++ in such a way as
to give the OP the info I thought was most important, without triggering
the nit picking, and I didn't quite pull it off.
Here's your badge. Here's your locker key. Toilets are down the hall, on the
left. Fire escape is out the back. You can use that coffee machine over
there. (This one here is private, I'm afraid. I get through a lot of
coffee, ever since the Incident Involving An Assertion Failure.)

Thanks, Richard! So I've got my locker, my "Troll" badge... what's next?
What if I shoot for getting through an entire week of posting at my average
frequency without choosing to click "Send Now" prematurely? (I know, I
should probably just try for one full day first, but I'm notorious for
over-reaching...)
-leor

Welcome to comp.lang.c.

Looking back at what I
wrote, I realize now I could have re-phrased the offending part in a
temporally-neutral manner, which would probably have been good enough. So
instead of:

That's what the ++ does, and its position on the right of its
operand ("postfix" notation) is what "delays" the incrementing until after
the old value has been sampled for use as the operand to *.

I might have said:

That's what the ++ does, and its position on the right of its operand
("postfix" notation) is what specifies that the "old" value of liftPtr is
used as the operand to '*'.

Better?

Yes, I think it's much improved. Specifically, it doesn't unwittingly assume
a particular implementation.

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Richard Heathfield]

Leor Zolman wrote:

On Sat, 3 Apr 2004 06:47:45 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

Leor Zolman wrote:

I just tried so /hard/ [...] to give the OP the info I thought
was most important, without triggering the nit picking, and I
didn't quite pull it off.

Here's your badge. Here's your locker key. Toilets are down the hall, on
the left. Fire escape is out the back. You can use that coffee machine
over there. (This one here is private, I'm afraid. I get through a lot of
coffee, ever since the Incident Involving An Assertion Failure.)

Thanks, Richard! So I've got my locker, my "Troll" badge... what's next?

Learn to use the fire escape. In comp.lang.c, it's an essential survival
skill.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Heathfield wrote:
| Leor Zolman wrote:
[snip]
|>Thanks, Richard! So I've got my locker, my "Troll" badge... what's next?
|
| Learn to use the fire escape. In comp.lang.c, it's an essential survival
| skill.

I think that Leor is probably familiar with the fire escape. He has a reputation
as an implementer to live down: "BDS C" to be precise

Hi, Leor.

Welcome back!

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFAb5NhagVFX4UWr64RAj6vAJdE0dxX1BVvq2+U/QJe0q2nrHDTAJ0c84X5
X0qb4pOUfOwhNlND1kTwWQ==
=kykt
-----END PGP SIGNATURE-----

[Richard Heathfield]

Lew Pitcher wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Heathfield wrote:
| Leor Zolman wrote:
[snip]
|>Thanks, Richard! So I've got my locker, my "Troll" badge... what's next?
|
| Learn to use the fire escape. In comp.lang.c, it's an essential survival
| skill.

I think that Leor is probably familiar with the fire escape. He has a
reputation as an implementer to live down:
Yes, so I gathered...

"BDS C" to be precise

Hi, Leor.

Welcome back!

....but I didn't know he was an ex-reg here. Which makes him a lot older than
me, of course. In fact, I expect his hair has gone all grey.

Me? Just a nipper, me.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Leor Zolman]

On Sun, 4 Apr 2004 07:42:48 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

Lew Pitcher wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Heathfield wrote:
| Leor Zolman wrote:
[snip]
|>Thanks, Richard! So I've got my locker, my "Troll" badge... what's next?
|
| Learn to use the fire escape. In comp.lang.c, it's an essential survival
| skill.

I think that Leor is probably familiar with the fire escape. He has a
reputation as an implementer to live down:

Yes, so I gathered...

"BDS C" to be precise

Hi, Leor.

Welcome back!

...but I didn't know he was an ex-reg here. Which makes him a lot older than
me, of course. In fact, I expect his hair has gone all grey.

But I wasn't! No, newsgroups weren't even really on my radar screen until I
began noticing posts about me and/or my tools (that's what prompted me to
release BDS C into the public domain), and I began to post in earnest upon
discovering alt.comp.lang.learn.c-c++, as a way to "keep in shape" during
the IT training work downturn. I soon learned (as I've described in a
post a while back) that the set of skills (or part of my brain) needed to
post effectively around here is not necessarily the same as what it takes
to be a decent classroom instructor, and I want to be good at /both/.

I pretty much shunned this group for a while after I started posting to
acllcc++; I was intimidated by it. But I managed to somehow get sucked in
against my better judgment ;-)

So I interpreted the "Welcome back" (thanks, Lew!) more as meaning
something like "Welcome back from obscurity".

I also mentioned very recently that I often have trouble with terminology;
so, I have to admit that the "fire escape" metaphor has so far gone right
over my head, although I guess it has something to do with ... OH! with
/flames/, right? Yeah, I can be dense sometimes.
-leor

P.S. One or two strands of gray show up once in a while, and my less
fortunate wife never misses an opportunity to point them out...
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Leor Zolman wrote:
[snip]
| So I interpreted the "Welcome back" (thanks, Lew!) more as meaning
| something like "Welcome back from obscurity".

Well, I didn't mean it in such a negative sense. <grin>

I /did/ mean something like "I'm glad you've come. I hope you stay."

[snip]
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAcNS6agVFX4UWr64RAsAOAKCZXECkb72jqbgDl4Orhh SB3r49vgCfcp2o
r+3VJGkgGRR8zbnPyLIIeWU=
=Zwvz
-----END PGP SIGNATURE-----

[Richard Heathfield]

Leor Zolman wrote:

P.S. One or two strands of gray show up once in a while, and my less
fortunate wife never misses an opportunity to point them out...

And how does your less fortunate wife react to your more fortunate wife? I
don't envy you, by the way; I couldn't live like that. :-)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Christopher Benson-Manica]

Michele <mi********@libero.it> spoke thus:

I'm sorry, maybe I'm too lazy...

You are, but that in itself is an important bit of knowledge. Try a
book or online references as others have suggested. Also, please read
the following documents related to this group.

http://www.ungerhu.com/jxh/clc.welcome.txt
http://www.eskimo.com/~scs/C-faq/top.html
http://benpfaff.org/writings/clc/off-topic.html

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.