twitter: comp.lang.c - 25 new messages in 8 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* substring finding problem! - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
* usage of size_t - 5 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* no investment earn part time - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e9016b1480907351?hl=en
* Efficency and the standard library - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* Scope of a variable declared in for loop - 8 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en
* unsigned char + constant - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/bf17ea9e38fd7565?hl=en
* automated test for sub-string search algorithms... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/38aee559668ee60c?hl=en
* Transmitting/receiving binary content portably - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/b2e3981dd7daef74?hl=en

==============================================================================
TOPIC: substring finding problem!
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 23 2010 1:20 pm
From: raltbos@xs4all.nl (Richard Bos)

Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:

> On 17 Feb, 21:14, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > The scanf function is basically a mess, and is rarely used correctly. I
> > am at a loss to understand why it is introduced so early in programming
> > texts.
>
> a former clc regular once posted
>
> ***
> The fscanf equivalent of fgets is so simple
> that it can be used inline whenever needed:-
> char s[NN + 1] = "", c;
> int rc = fscanf(fp, "%NN[^\n]%1[\n]", s, &c);
> if (rc == 1) fscanf("%*[^\n]%*c);
> if (rc == 0) getc(fp);
> ***

That sounds suspiciously like either Dan Pop, who had a bee in his
bonnet regarding scanf() (amongst others), or like someone employing
irony at said Mr. Pop.

> I think scanf() is seen as a straight forward way to read simple
> unvalidated input. I'm not convinced that's a good idea.

It's a very bad idea. sscanf() can be a reasonable way to read simple
_validated_ input. Unvalidated, none of that family is useable.

Richard

== 2 of 3 ==
Date: Tues, Feb 23 2010 2:54 pm
From: "Chris M. Thomasson"

<blmblm@myrealbox.com> wrote in message
news:7ui26oFieaU1@mid.individual.net...
> In article
> <0.0ddf9db924489b8a3417.20100222180827GMT.87wry5b0tg.fsf@bsb.me.uk>,
[...]

> I've been posting total times only to save space and haven't been
> looking carefully at whether code that's faster overall is also
> faster for each individual test.
>
> Results with gcc 4.4.1, as described above .... :
>
> bacarisse (O2) 1.74 seconds
> bacarisse (O3) 1.75 seconds
> blmblm (O2) 2.52 seconds
> blmblm (O3) 2.48 seconds
> harter-1 (O2) 2.58 seconds
> harter-1 (O3) 2.49 seconds
> harter-2 (O2) 2.27 seconds
> harter-2 (O3) 2.24 seconds
> io_x (O2) 9.82 seconds
> nilges (O2) 2.36 seconds
> nilges (O3) 2.35 seconds
> thomasson (O2) 1.69 seconds
> thomasson (O3) 1.68 seconds
> willem (O2) 2.77 seconds
> willem (O3) 4.16 seconds [ can this be right?! ]

FWIW, I always try to "prime" the program by making several dummy runs the
same data set. After that, I time several iterations of it on the same data
set, and report the average. Humm, when I get some time, I think I will
create another "entry" that uses a non-naive sub-string search algorithm:

http://groups.google.com/group/comp.lang.c/msg/825cf5bd46ad4a9f

I think it will be interesting to see how it effects your timing results.

== 3 of 3 ==
Date: Tues, Feb 23 2010 3:05 pm
From: Ben Bacarisse

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:

> In article <0.0ddf9db924489b8a3417.20100222180827GMT.87wry5b0tg.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
<snip>
>> I used -O3 throughout. I'll post the -O2 with -O2 as well but in my
>> case I get faster time in all cases using -O3 (gcc 4.4.1).
>
> My results posted thus far were with gcc 4.0.1 (and glibc 2.3.5).
> When I repeat the experiment, on a newer/faster system, with
> gcc 4.4.1 (and glibc 2.10.1), I also find that -O3 is *almost*
> always faster (and the one exception -- perhaps I need to rerun
> the test, in case there was something else going on on the machine
> that skewed results). Results below.

If that odd -O3 result goes away, it means we can largely ignore
-O2/-O3 differences. That halves the data.

>> <snip>
>> I assume these results are for 4004 byte long strings with 2 short
>> replacements.
>
> No, this is with my full test suite (such as it is):
>
> 4004-byte input, 2 short replacements (2/2)
> 4020-byte input, 10 short replacements (2/2)
> 4100-byte input, 50 short replacements (2/2)
> 4500-byte input, 50 slightly-longer replacements (10/10)

Ah, I see. I've made up data files with these properties and re-run
my tests. I've scaled the per call times up by 20,000 (I remember you
used 20,000 calls) and I've aggregated the times for these four tests
for all of the methods I can time.

<snip>
> (Differences in input length are because I was lazy in coding
> Results with gcc 4.4.1, as described above .... :
>
> bacarisse (O2) 1.74 seconds
> bacarisse (O3) 1.75 seconds
> blmblm (O2) 2.52 seconds
> blmblm (O3) 2.48 seconds
> harter-1 (O2) 2.58 seconds
> harter-1 (O3) 2.49 seconds
> harter-2 (O2) 2.27 seconds
> harter-2 (O3) 2.24 seconds
> io_x (O2) 9.82 seconds
> nilges (O2) 2.36 seconds
> nilges (O3) 2.35 seconds
> thomasson (O2) 1.69 seconds
> thomasson (O3) 1.68 seconds
> willem (O2) 2.77 seconds
> willem (O3) 4.16 seconds [ can this be right?! ]

Looks wacky to me! Is it repeatable?

Here are my times (also gcc 4.4.1 and libc 2.10.1). I seem to have a
faster machine. The first number are your times (for reference) and
the second are mine (in seconds). The third column is the ratio of
the two. You can see that there is more going on than just the speed
of the machine.

bacarisse (O2) 1.74 0.426 4.08
bacarisse (O3) 1.75 0.400 4.38
blmblm (O2) 2.52 0.540 4.67
blmblm (O3) 2.48 0.501 4.95
harter-1 (O2) 2.58 0.857 3.01
harter-1 (O3) 2.49 0.803 3.10
harter-2 (O2) 2.27 0.780 2.91
harter-2 (O3) 2.24 0.722 3.10
io_x No data
nilges (O2) 2.36 0.881 2.68
nilges (O3) 2.35 0.861 2.73
thomasson (O2) 1.69 0.380 4.45
thomasson (O3) 1.68 0.364 4.62
willem (O2) 2.77 0.813 3.41
willem (O3) 4.16 0.885 4.70

If we are now measuring the same things, it seems that some code is
favoured by my system (yours for example) and some does not do so
well. I suspect interactions with the various caches but that is a
huge guess.

My other tests show that the rank can be switched round a lot by using
shorter strings. To get a more balanced view, the tests would have to
range over various string lengths, but I doubt that there can be any
idea of the "best" way to do this based on speed. Clear simple code
will always win out for me in these situations, despite my love of
generating (ultimately pointless) data like this.

--
Ben.

==============================================================================
TOPIC: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Feb 23 2010 1:20 pm
From: raltbos@xs4all.nl (Richard Bos)

gwowen <gwowen@gmail.com> wrote:

> On Feb 22, 11:31=A0am, Richard <rgrd...@gmail.com> wrote:
>
> > The -- in the loop is a well known C usage and if its not clear to you
> > then your C is hazy to say the least. It is much more confusing and hard
> > to read to put the decrement on some line in the body.
>
> Your code is clear for people with good C skills.
> My code is clear for people without good C skills, and clear (but non-
> idiomatic) for those with good skills, and clear-but-hideous for C
> mavens. I'm OK with that.

People without good C skills should learn a bit more before trying to
hack on a program written in C. If you want COBOL, you know where to
find it.

> So, if you want your code understood as widely as possible, don't be a
> vicar of Bray; grasp the nettle, and do Yeoman's service and all
> things being equal, Bob's your uncle and you'll come up smelling of
> roses... Otherwise you'll do a Devon Loch, be hoist by your own
> petard, be gone for a right royal Burton, or otherwise come a
> cropper. I wouldn't touch idiomatic English with a bargepole. It's
> just not cricket.

And yet, I would prefer a novel written in English for literate readers
_not_ to eschew idioms. You should compare C to a Shaw play or a book by
Joyce. Do not write C as if you are Dr. Seuss - that's what BASIC is
for.

Richard

== 2 of 5 ==
Date: Tues, Feb 23 2010 1:37 pm
From: Keith Thompson

raltbos@xs4all.nl (Richard Bos) writes:
[...]
> ...because this is nonsense. There have been _many_ situations in which
> sizeof(void *) != sizeof (size_t) != sizeof (int).

I don't think I've ever used a system where sizeof(void*) != sizeof(size_t).

That's not to say that such systems don't exist, of course, but on
most modern systems with a linear monolithic address space, it makes
sense for void* and size_t to be the same size.

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

== 3 of 5 ==
Date: Tues, Feb 23 2010 2:49 pm
From: Seebs

On 2010-02-23, Richard Bos <raltbos@xs4all.nl> wrote:
> And yet, I would prefer a novel written in English for literate readers
> _not_ to eschew idioms. You should compare C to a Shaw play or a book by
> Joyce. Do not write C as if you are Dr. Seuss - that's what BASIC is
> for.

I have to take some exception to this, because Dr. Seuss was actually an
extremely skilled writer of English, even though many of his books don't
make this obvious to casual observation.

... But the point is still valid. Idiomatic writing is used because it is
clearer and more communicative, and yes, that does impose the cost of learning
the idioms on the reader. It's still worth it.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 4 of 5 ==
Date: Tues, Feb 23 2010 3:09 pm
From: Peter Nilsson

Keith Thompson <ks...@mib.org> wrote:
> ralt...@xs4all.nl (Richard Bos) writes:
> > ...because this is nonsense. There have been _many_
> > situations in which sizeof(void *) != sizeof (size_t)
> > != sizeof (int).
>
> I don't think I've ever used a system where sizeof(void*)
> != sizeof(size_t).

I think it's more common for size_t to match unsigned long,
rather than being dependant on the size of void *. N1256 has
a 'recommended practice'...

"The types used for size_t and ptrdiff_t should not
have an integer conversion rank greater than that of
signed long int unless the implementation supports
objects large enough to make this necessary."

There must be 64-bit systems where it's possible, but
not _necessary_, to make unsigned long and size_t larger
than 32-bit.

> That's not to say that such systems don't exist, of course,

Early 68k based Macs were capable of addressing 16M, but most
applications still had to fit into 32K, or 32K chunks stored
in the resource fork of the application. Many applications
were actually limited to using less than 32K in total. So it
wouldn't surprise me if there were some early mac C
implementations where pointers were 32-bit, but size_t and
int were only 16-bit due to the relative cost of 32-bit
operations and storage. [The 68k processor had separate
data and address registers. Even though they were all 32-bit,
16-bit operations on data registers were quicker than 32-bit
ones.]

> but on most modern systems with a linear monolithic address
> space, it makes sense for void* and size_t to be the same
> size.

Why? Serious question! It's a very common assumption, but
not one that's guaranteed by the standard. Size_t is only
required to be able to store the size of one object (more
precisely the result of sizeof.) It isn't required to be
large enough to store the combined size of all objects.

Recall the calloc kerfuffle and the possibility of creating
objects too big to fit in a size_t! Whilst I think that was
ruled out, the question remains as to whether C allows a
program to allocate more combined space than will fit in
a size_t.

--
Peter

== 5 of 5 ==
Date: Tues, Feb 23 2010 3:31 pm
From: Keith Thompson

Peter Nilsson <airia@acay.com.au> writes:
> Keith Thompson <ks...@mib.org> wrote:
>> ralt...@xs4all.nl (Richard Bos) writes:
>> > ...because this is nonsense. There have been _many_
>> > situations in which sizeof(void *) != sizeof (size_t)
>> > != sizeof (int).
>>
>> I don't think I've ever used a system where sizeof(void*)
>> != sizeof(size_t).
>
> I think it's more common for size_t to match unsigned long,
> rather than being dependant on the size of void *.

For what it's worth (which isn't a whole lot), every system I've
checked has size_t, unsigned long, and void* all the same size.

> N1256 has
> a 'recommended practice'...
>
> "The types used for size_t and ptrdiff_t should not
> have an integer conversion rank greater than that of
> signed long int unless the implementation supports
> objects large enough to make this necessary."

I've never seen a system that violates this recommendation.

> There must be 64-bit systems where it's possible, but
> not _necessary_, to make unsigned long and size_t larger
> than 32-bit.

Sure, but all the 64-bit systems I've seen have 64-bit unsigned long.
(I vaguely recall that 64-bit Windows has 32-bit unsigned long; I
don't know what it uses for size_t.)

>> That's not to say that such systems don't exist, of course,
>
> Early 68k based Macs were capable of addressing 16M, but most
> applications still had to fit into 32K, or 32K chunks stored
> in the resource fork of the application. Many applications
> were actually limited to using less than 32K in total. So it
> wouldn't surprise me if there were some early mac C
> implementations where pointers were 32-bit, but size_t and
> int were only 16-bit due to the relative cost of 32-bit
> operations and storage. [The 68k processor had separate
> data and address registers. Even though they were all 32-bit,
> 16-bit operations on data registers were quicker than 32-bit
> ones.]

Sure, if the maximum size of a single object is smaller than the
total addressing space (e.g., because an object must fit into a
single memory segment), it makes sense for size_t to be smaller
than void*.

>> but on most modern systems with a linear monolithic address
>> space, it makes sense for void* and size_t to be the same
>> size.
>
> Why? Serious question! It's a very common assumption, but
> not one that's guaranteed by the standard. Size_t is only
> required to be able to store the size of one object (more
> precisely the result of sizeof.) It isn't required to be
> large enough to store the combined size of all objects.

Absolutely. But most modern systems (at least the ones I've been
exposed to) have a monolithic linear address space, where the size of
a single object, at least in principle, has the same upper bound as
the size of all of memory. Smaller limits might be imposed by the
operating system, but those limits aren't typically enforced by the
compiler by making size_t smaller than void*.

> Recall the calloc kerfuffle and the possibility of creating
> objects too big to fit in a size_t! Whilst I think that was
> ruled out, the question remains as to whether C allows a
> program to allocate more combined space than will fit in
> a size_t.

I suspect that's not quite what you meant to say.

There's some question whether a single object can be bigger than
SIZE_MAX bytes, but I'm quite sure that the language doesn't require
the total size of all objects to be no bigger than INT_MAX.

For example, on system with 64-bit void* and 32-bit size_t (and
sufficient resources), a single object arguably couldn't be bigger
than 4 gigabytes, but you could have 1000 distinct 1-gigabyte objects.

==============================================================================
TOPIC: no investment earn part time
http://groups.google.com/group/comp.lang.c/t/e9016b1480907351?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 1:20 pm
From: raltbos@xs4all.nl (Richard Bos)

joag <jag1506@hotmail.com> wrote:

> As I see is just for indians so why do you post this as if everybody
> would like this kind of job?

Why do you expect spammers to read your replies?

Richard

==============================================================================
TOPIC: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 23 2010 1:20 pm
From: raltbos@xs4all.nl (Richard Bos)

santosh <santosh.k83@gmail.com> wrote:

> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > On Feb 22, 4:13 pm, santosh <santosh....@gmail.com> wrote:
> >>
> >> Regardless of whether he is or is not a master programmer, don't
> >> they (the publishers) realise that many readers are actually
> >> likely to be put-off by these overly hyped descriptions?
> >>
> >>
> > I wouldn't tell a marketing person what to put on the blurb of a
> > dustjacket, any more than I would expect a marketing person to tell
> > me how to design a video game.
>
> Even if I were a very good C programmer, I'd object to any publisher
> who decided to describe me as "world famous programmer" on any C book
> I were to write. Not everything is about marketing. I know evaluating
> a book based on an emotional reaction to it's blurb is weak, but
> still...

You seem to be mistaken about who the intended public for these books
are. They are in the "...in 24 hours" and "...for dummies" class, and
like those, are not marketed towards serious programmers.

Richard

== 2 of 2 ==
Date: Tues, Feb 23 2010 4:48 pm
From: "Chris M. Thomasson"

"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:AFGen.96634$U83.407@newsfe10.iad...
> "Seebs" <usenet-nospam@seebs.net> wrote in message
> news:slrnhnmavs.3pi.usenet-nospam@guild.seebs.net...
>> On 2010-02-16, Chris M. Thomasson <no@spam.invalid> wrote:
>>> IMVHO, a linked-list amortized string implementation can get along
>>> fairly
>>> well with a "large" amount of text. For instance, I would personally not
>>> want to store the text that makes up a fairly verbose well-read novel in
>>> a
>>> single NUL terminated string. Humm... You should probably break the
>>> massive
>>> data apart into an amortized linked data-structure. Amortized in the
>>> sense
>>> that multiple characters/whatever can exist on a per-node basis.
>>
>> Anyone planning to invent this would be well-served by studying the
>> "mbufs"
>> in the BSD networking stack.
>
> Indeed. I also enjoy the well known intrusive list technique:
> _______________________________________________________
> struct node
> {
> struct node* next;
> };
>
>
> struct foo
> {
> struct node node;
> /* [whatever] */
> };
>
>
> #define foo_from_node(n) ((struct foo*)(n))
> _______________________________________________________
>
>
>
>
> The Linux User/Kernel and Windows User/Kernel-space code is quite fond of
> intrusive data-structures as well.

Example from Windows:

http://msdn.microsoft.com/en-us/library/ms684121(VS.85).aspx

Take note of the node data-structure:

http://msdn.microsoft.com/en-us/library/ms686309(VS.85).aspx

They use no void* pointers, because the user could easily extend the
structure if they wish:

struct Custom_Node
{
SLIST_ENTRY SList_Node;
void* Object;
};

==============================================================================
TOPIC: Scope of a variable declared in for loop
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en
==============================================================================

== 1 of 8 ==
Date: Tues, Feb 23 2010 1:26 pm
From: Seebs

On 2010-02-23, Keith Thompson <kst-u@mib.org> wrote:
> It was revised in this way, apparently before C99 picked up the
> feature. (Declarations in conditions are another C++ feature that
> C99 didn't adopt.)

In the C99 discussion, we weren't sure which way C++ went, but we
decided to just do the scope correctly regardless, as I recall.

Happily, this turned out not to be an incompatibility.

== 2 of 8 ==
Date: Tues, Feb 23 2010 2:43 pm
From: jacob navia

Mark Bluemel a écrit :
> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>> Hi,
>> A)Is it possible to declare a variable inside for loop like
>> for(int i=100;i>=0;i--);
>
> Not in C.
>
> Variables can be declared inside a block (i.e. between braces) but not
> in the context you are talking about.
>
>> if yes what is the scope of that variable?
>
> The question does not arise.

You are completely wrong. Standard C allows that declaration and the scope
is the scope of the for block.

Read the standard before answering please

== 3 of 8 ==
Date: Tues, Feb 23 2010 2:45 pm
From: jacob navia

Alexander Bartolich a écrit :
> vaysagekv wrote:
>> [...]
>> A)Is it possible to declare a variable inside for loop like
>> for(int i=100;i>=0;i--);
>
> You can do this in C99 and C++, but not in preceding C standards.
> Given the low popularity of C99 amongst compiler vendors I recommend
> against using its features.
>

Standard C is implemented in most systems. This person is just talking nonsense

== 4 of 8 ==
Date: Tues, Feb 23 2010 2:57 pm
From: Richard Heathfield

jacob navia wrote:
> Alexander Bartolich a écrit :
>> vaysagekv wrote:
>>> [...]
>>> A)Is it possible to declare a variable inside for loop like
>>> for(int i=100;i>=0;i--);
>>
>> You can do this in C99 and C++, but not in preceding C standards.
>> Given the low popularity of C99 amongst compiler vendors I recommend
>> against using its features.
>>
>
> Standard C is implemented in most systems.

Well, C90 is. I would suggest that C99 has yet to justify so bold a claim.

> This person is just talking nonsense

No, he's talking common sense. You, on the other hand, are talking
emotive crap. Why do you get so worked up about it?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 5 of 8 ==
Date: Tues, Feb 23 2010 2:51 pm
From: Richard

Mark Bluemel <mark.bluemel@googlemail.com> writes:

> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>> Hi,
>> A)Is it possible to declare a variable inside for loop like
>> for(int i=100;i>=0;i--);
>
> Not in C.

Huh? What C do you use?

Not only can you, its recommended.

>
> Variables can be declared inside a block (i.e. between braces) but not
> in the context you are talking about.
>
>> if yes what is the scope of that variable?
>
> The question does not arise.

I'm afraid it does.

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

== 6 of 8 ==
Date: Tues, Feb 23 2010 3:00 pm
From: Keith Thompson

jacob navia <jacob@nospam.org> writes:
> Alexander Bartolich a écrit :
>> vaysagekv wrote:
>>> [...]
>>> A)Is it possible to declare a variable inside for loop like
>>> for(int i=100;i>=0;i--);
>>
>> You can do this in C99 and C++, but not in preceding C standards.
>> Given the low popularity of C99 amongst compiler vendors I recommend
>> against using its features.
>>
>
> Standard C is implemented in most systems. This person is just
> talking nonsense

There are plenty of compilers that don't implement, or don't fully
implement, the C99 standard. Support for the C90 standard, on the
other hand, is almost universal.

On the other hand, there are also plenty of compilers that do support
some C99 features, and declarations in for statements are probably
one of the most common implemented features (behind // comments,
I'd guess).

You'll need to decide for yourself whether using C99-specific
features is worth the (perhaps small) loss of portability.
The situation is not as simple as jacob claims it is -- or as both
jacob and I wish it were.

== 7 of 8 ==
Date: Tues, Feb 23 2010 2:53 pm
From: Seebs

On 2010-02-23, jacob navia <jacob@nospam.org> wrote:
> Alexander Bartolich a �crit :
>> You can do this in C99 and C++, but not in preceding C standards.
>> Given the low popularity of C99 amongst compiler vendors I recommend
>> against using its features.

> Standard C is implemented in most systems. This person is just talking
> nonsense

Off the top of my head, I cannot name a single complete implementation.

On the other hand, I don't think I've used any compiler this millennium which
doesn't support declarations in for loops. It's an especially likely feature
simply because so many C compilers are bundled with C++ compilers, meaning
the developer has almost certainly solved this problem.

== 8 of 8 ==
Date: Tues, Feb 23 2010 4:32 pm
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <ko2e57-q2n.ln1@news.eternal-september.org>,
Richard <rgrdev_@gmail.com> wrote:
>Mark Bluemel <mark.bluemel@googlemail.com> writes:
>
>> On 23 Feb, 13:35, vaysagekv <kvvays...@gmail.com> wrote:
>>> Hi,
>>> A)Is it possible to declare a variable inside for loop like
>>> for(int i=100;i>=0;i--);
>>
>> Not in C.
>
>Huh? What C do you use?
>
>Not only can you, its recommended.

In the religion of comp.lang.c, nothing exists past C89.

Therefore, it (the declarations which are the subject of this thread)
does not exist.

==============================================================================
TOPIC: unsigned char + constant
http://groups.google.com/group/comp.lang.c/t/bf17ea9e38fd7565?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 23 2010 2:31 pm
From: Peter Nilsson

On Feb 24, 8:20 am, ralt...@xs4all.nl (Richard Bos) wrote:
> Peter Nilsson <ai...@acay.com.au> wrote:
> > On such implementations INT_MAX < UCHAR_MAX.
>
> Not allowed. 6.2.5#8 in C99:

Yes it is.

> # 8 For any two integer types with the same signedness and
^^^^^^^^^^^^^^^
> # different integer conversion rank (see 6.3.1.1), the range
> # of values of the type with smaller integer conversion rank
> # is a subrange of the values of the other type.

There are many implementations today where INT_MAX < USHRT_MAX.

--
Peter

== 2 of 2 ==
Date: Tues, Feb 23 2010 2:36 pm
From: Peter Nilsson

"lovecreatesbea...@gmail.c0m" <lovecreatesbea...@gmail.com> wrote:
> Peter Nilsson <ai...@acay.com.au> wrote:
> > "barcaroller" <barcarol...@music.net> wrote:
> > > ...
> > > if ((x+1) < y)
> > ...
> > If you want the mathematical condition to hold, then the
> > second clause can be written portably as...
> >
> > if (y != 0 && x < y - 1)
> >
> > The original code can fail in the case where y is non-zero
> > and x has the value UCHAR_MAX, and x promotes to unsigned
> > int. In that case x + 1 will yield 0 (as an unsigned int)
> > which of course compares less than a positive value, even
> > if y has a positive value lower UCHAR_MAX.
>
> ...I think Op's code doesn't fail. OP's code will fail when
> x types of unsigned int and y types of long. Integral
> expression defaults to int,

No, promotion to unsigned int is possible if int cannot
represent the values of an expression.

> so x+1 with x equals to UCHAR_MAX won't yields 0,

It can if INT_MAX < UCHAR_MAX, e.g. embedded systems
(freestanding implementations) where integer types
are all the same size, say 32 or 64-bit.

> but value of UCHAR_MAX+1 types of int.

On most hosted implementations, yes.

--
Peter

==============================================================================
TOPIC: automated test for sub-string search algorithms...
http://groups.google.com/group/comp.lang.c/t/38aee559668ee60c?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 3:40 pm
From: "Chris M. Thomasson"

"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:uLugn.5580$Cw3.280@newsfe21.iad...
> "Chris M. Thomasson" <no@spam.invalid> wrote in message
> news:BaZfn.2632$BD2.598@newsfe14.iad...
>> This code includes my sub-string search algorithm, the automated test,
>> and a stress test for my algorithm:
>>
>>
>> http://clc.pastebin.com/f5cb3bbd2
>>
>>
>> This testing framework helped me find several bugs in my algorithm. I
>> have fixed them and so far, so good... I will continue to blast the shi%
>> out of my algorithm with this test and report any errors here.
>
> Here is latest version of my sub-string search algorithm:
>
>
> http://clc.pastebin.com/f5c1d3e5a
>
>
> This one allows search to skip many more characters than before. I don't
> think its like Boyer-Moore because I am not using two tables. Humm...
>
>
> Any thoughts?

I would say it's close to the following algorithm:

http://en.wikipedia.org/wiki/Boyer-Moore-Horspool_algorithm

I think I am initializing the hash table a little bit differently. For
instance, my bad character hash hit is zero, while the Horspool algorithm
would have the length of the comparand stored in the table.

==============================================================================
TOPIC: Transmitting/receiving binary content portably
http://groups.google.com/group/comp.lang.c/t/b2e3981dd7daef74?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 23 2010 3:57 pm
From: Clint O

On Feb 22, 10:59 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> There's a recent thread on writing a floating point value portably.

Ok, I'll see if I can find it.

> Integers are easy. You just break them down byte by byte and read/
> write the bytes. The only tricky bit is sign-extending negatives where
> the machine width is greater than the width of the data.

Ahh yes, I hadn't considered that. In fact I tried to send (-1) over
and I received a properly extended 32-bit value, but I'm not sure how
I would recover that on the receiving side.

% ./putlong | ./getlong
Outputting 18446744073709551615
Received 4294967295

Thanks,

-Clint

== 2 of 3 ==
Date: Tues, Feb 23 2010 4:33 pm
From: Ben Bacarisse

Clint O <clint.olsen@gmail.com> writes:

> On Feb 23, 4:27 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> I think the author (Rob Pike) knew what he was doing but the OP has
>> misrepresented what this code is for. The paper is about Plan 9
>> programming and the Plan 9 C compiler that "accept[s] a dialect of
>> ANSI C". The code is for moving data about within Plan 9 where "the
>> operating system is fixed and the compiler, headers and libraries are
>> constant so most of the stumbling blocks to portability are removed".
>
> I didn't misrepresent anything. I posted the link specifically so
> that people could go and read the background context for his code so
> they knew why he did what he did. It was I who then posed the
> question about the viability of using this mechanism for transporting
> data in a binary fashion in a more general sense.

That's true and I am sorry that my remark was so definite. The
appearance of misrepresenting the code come simply from posting it in
comp.lang.c where portability usually means between C
implementations. Plan 9 has an curious definition of "portable C"
that is not the most common one here.

Eric would not have been surprised had you flagged the code as not
portable in the c.l.c sense bit only in the Plan 9 sense. Not
everyone has the time to read all the references!

My apologies for misrepresenting *you*.

--
Ben.

== 3 of 3 ==
Date: Tues, Feb 23 2010 4:58 pm
From: Ben Bacarisse

Clint O <clint.olsen@gmail.com> writes:

> On Feb 22, 10:59 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>> There's a recent thread on writing a floating point value portably.
>
> Ok, I'll see if I can find it.
>
>> Integers are easy. You just break them down byte by byte and read/
>> write the bytes. The only tricky bit is sign-extending negatives where
>> the machine width is greater than the width of the data.
>
> Ahh yes, I hadn't considered that. In fact I tried to send (-1) over
> and I received a properly extended 32-bit value, but I'm not sure how
> I would recover that on the receiving side.
>
> % ./putlong | ./getlong
> Outputting 18446744073709551615
> Received 4294967295

It might help to take a step back. If the "wire" format you define is
simply 32 bits and 2's complement (with a specified order of
significance for the consecutive octets) then you can't distinguish
between -1 and 4294967295. The receiver just can't know what it
should do when it sees 32 bits all set to 1.

There has to be some more data somewhere. It can be assumed ("all
data is unsigned") or it can be explicit, say by also sending a
signedness and width code. This has the advantage of making the data
stream closer to being self-describing.

Once you pin that down, you will hit the issue the Malcolm is
describing. In general, if either end does not have a type whose
properties match the wire type, your task gets considerably harder.
Can you rule out 1's complement and sign-magnitude machines? Can you
rule out machines that don't have 8-bit bytes and 16, 32 and 64 bit
integer types (with no padding bits)?

--
Ben.

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

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

twitter

Tuesday, February 23, 2010

comp.lang.c - 25 new messages in 8 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts