comp.lang.c - 4 new messages in 4 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Pointer Question II - The Rebirth - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/17bf09bb220a8480?hl=en
* [the free NGs are in the way of the end] - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/170ce6d2aa31e130?hl=en
* defining a boolean type - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/fcfa31f0e0473e4f?hl=en
* memset() on a struct or union - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e41e9c30b0f7a050?hl=en

==============================================================================
TOPIC: Pointer Question II - The Rebirth
http://groups.google.com/group/comp.lang.c/t/17bf09bb220a8480?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 2 2010 10:28 pm
From: DSF

On Tue, 02 Feb 2010 12:01:23 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>DSF <notavalid@address.here> writes:
>
{snip}
>> This brings up an interesting question: why do many (all?) of the
>> string functions return a copy of the "destination" string? Is it
>> just for the convenience of being able to use the function itself in
>> code requiring a char * instead of calling the function and then
>> passing the pointer to the code requiring a char * on another line?
>
>"Just for the convenience" does not do that notion justice. What
>reason could there be for not returning a value if there is a value
>that might reasonably be returned? The question is then simply which
>value should be returned and the destination is a clear winner in most
>cases.
I guess what I was getting at is that the string function can sit in
place of, but not take the place of a variable.

strcpy(string1, strcpy(string2, string3));

Is functionally the same as:

strcpy(string2, string3);
strcpy(string1, string2);

I had an example of what I mean, but I can't find it. Something
where string2 above was only a placeholder-a buffer to get from
string3 to string1. It's really not important though, and I do
understand your point.

>
>> Here's the updated code: (Name's still the same, for now.)
>>
>> int StringDelete(char *str, size_t pos, size_t n)
>> {
>> char *p1;
>> char *p2;
>
>I'd define these inside the next block, but that is matter of taste
>and style.
>
>> size_t l = strlen(str);
>>
>> if(pos < l && !((pos + n) < n))
>
>What is that second test all about?

No "mystery." The reason is in the part of my reply to Peter
Nilsson that was snipped. The second part above simply tests pos + n
for overflow. Off the top of my head (untested) I guess it could have
been stated as ((pos + n) >= n) and lose the !, but it does work as
written.

>
>> {
>> if(pos + n > l)
>> n = l - pos;
>
>Ah, maybe you are worried about the possibility that pos+n is bigger
>than SIZE_MAX. I would test if n > l - pos and adjust if needed and
>delete the "mystery" test in the previous if.

See above. I really don't think it's all that "mysterious." ;o)

>
>> p1 = str + pos;
>> p2 = p1 + n;
>>
>> while(*p2)
>> *p1++ = *p2++;
>> *p1 = *p2;
>
>This is what memmove is for.

Yeah, I know. But I figured making a wide (16 bit character)
version of this function would be a lot easier. Just change all char
to wchar_t and use the wide version of strlen. However,since its
companion function "StringInsert" already uses memmove, and memmove
will be faster except on the shortest strings (or if pos+n >= l, in
which case it merely plops a 0 in str[n]).

>
>> return 0;
>> }
>> return 1;
>> }
>
>Odd return values, but I've seen your explanation of why.

The conventional method would be to return str unaltered, but I
figure returning "Hey you! Either pos or n is out of range or str is
shorter that you thought!" would be much more useful for debugging or
error handling. :o)

DSF

==============================================================================
TOPIC: [the free NGs are in the way of the end]
http://groups.google.com/group/comp.lang.c/t/170ce6d2aa31e130?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 2 2010 11:25 pm
From: "abbassiOGM"

"Noob" <root@127.0.0.1> ha scritto nel messaggio
news:hk97qm$15q$1@speranza.aioe.org...
> abbassiOGM wrote:
>
>> who was the one that allow ngs
>> to cancel one message even if who cancel
>> is not who write messages?
>>
>> can i know the name?
>
> Tom Truscott and Jim Ellis. Now what?
>
> (http://en.wikipedia.org/wiki/Usenet )

there is someone that see my messages
even if someone cancell the first one.

but why Verizon Communications, Time Warner Cable,
Sprint Nextel, AOL, AT&T has close their news groups services?

==============================================================================
TOPIC: defining a boolean type
http://groups.google.com/group/comp.lang.c/t/fcfa31f0e0473e4f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 2 2010 11:22 pm
From: Nick <3-nospam@temporary-address.org.uk>

"Rod Pemberton" <do_not_have@havenone.cmm> writes:

> "Seebs" <usenet-nospam@seebs.net> wrote in message
> news:slrnhmf210.hkn.usenet-nospam@guild.seebs.net...
>
>> Here's my thought: Consider a single bit. It's either zero or one.
>>
>> The non-zero value is 1. Otherwise, you have the problem that
>>
>> ((unsigned short) true == (int) true)
>>
>> might be untrue.
>
> Did I miss something? C has that problem currently. So, what's your point?

It does if the "true" in the line of code means "an arbitrary value that
is true". But Seebs' point is about the value you've chosen to define
the symbol "true" as. If it's 1, as he's arguing, then whatever you
cast it to will still be 1. If it's -1, as you were arguing, then these
two casts can yield values that don't compare equal.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: memset() on a struct or union
http://groups.google.com/group/comp.lang.c/t/e41e9c30b0f7a050?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 2 2010 11:31 pm
From: Nick <3-nospam@temporary-address.org.uk>

Joe Wright <joewwright@comcast.net> writes:

> Look up "metre" in any dictionary you have to hand. You will be
> referred to "meter" is every case. Even La Rousse.

By co-incidence I had Chamber's dictionary sitting such that I could
pick it up without moving in or from my seat. That's about as "to hand"
as you could get.

So I looked up "metre". Here's the first couple of lines of the entries
(with some adaptation for ASCII only):

"*metre*(1) or (US) *meter* [pronunciation] /n/ the regulated succession
of groups of syllables ...."

"*metre*(2) or (US) *meter* [pronunciation] /n/ the fundamental unit of
length in the metric system ...

It appears that you're wrong.

Just to really confirm this, there are two entries for "meter". The
first is "a measurer, an apparatus for measuring" and the second I quote
in it's entirety:

"*Meter*(2) US spelling of *metre*(1,2)
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en