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

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Feb 27 2010 3:23 pm
From: Kelsey Bjarnason

On Sat, 27 Feb 2010 08:38:08 -0800, Nick Keighley wrote:

> On 27 Feb, 05:32, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
>> On Fri, 26 Feb 2010 12:29:13 +0000, Tim Streater wrote:
>
>> > Trouble with tabs is, what is a tab?
>>
>> It's a character, often ASCII 9, which tells your editor to indent (or,
>> on removal, unindent) by whatever number of columns is required to
>> bring things in line with the next (previous) tab stop.
>
> so your layout is tab-stop dependent

And variable, to the individual coder's tastes, simply by their choice of
tab stops, without messing it up for everyone else. Yes, indeed, tab-
stop dependent, not "whatever number of spaces I think should be inserted
here" dependent.

>> Contrast that to hitting delete on a line which uses spaces instead of
>> tabs. All this does is mess up the formatting, as the editor is almost
>> certain to treat a space as a _space_, as it should, not as a tab,
>> which it _shouldn't_, because the character involved is not a tab, but
>> a space.
>
> get a better editor

I have a better editor. One that understands the difference between
spaces and tabs. One that does *not* do something as brain-dead as
deleting _multiple_ characters when I press delete once. Any editor
which deletes multiple items on a single delete simply cannot be trusted,
it's liable to destroy something.

>> Then, of course, there's inserting. Hit space. See how many columns
>> the line indents. One, isn't it?
>
> but if I hit 'tab'

No, sorry, we're using spaces here, not tabs. If you want to insert
tabs, then by all means, use tabs. But then you're on my side of the
fence, with spaces being defective by design for indent. If they weren't
defective by design, you wouldn't be using tab instead of space.

>> Why is that? Oh, yes, because spaces
>> aren't tabs, and editors won't treat them as tabs. Tabs are tabs, and
>> editors treat them that way.
>
> mine doesn't

Then you should get an editor that works.

>> or, when you
>> hit the spacebar, correctly figures out that you actually meant a tab,
>> not a space, and thus inserts 4 (or is it 3? 8? 5?) spaces.
>
> but TAB does that for me

Exactly. Tab. Not space.

If your editor - and the notion of spaces for indentation - weren't
defective by design, you wouldn't need to use a special key to insert
spaces; that's why you have a space bar. The fact you have to resort to
something entirely different, the tab key, is prima facie evidence the
whole notion of spaces to indent is as defective as it appears.

Now, if your editor worked properly, using tabs instead of spaces, with
the tab key inserting tabs as it should, then when viewed on someone
else's display, rather than yours, it would show the code as *they*
prefer to view it, rather than as *you* have decided is the only true way
which everyone should be forced to view it in.

Really, isn't this just a case of imposing your own layout conventions on
others, rather than using a common sense approach which actually lets
everyone view the code in their own preferred manner? Without having to
defeat the needless additional complication of converting some godawful
arrangement you happen to like into something actually manageable?

== 2 of 4 ==
Date: Sat, Feb 27 2010 4:08 pm
From: Ben Finney

Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>
writes:

> > Set tabstop to 2, 3, 4, 5, 8, 179, whatever looks best to your
> > preferences.
> >
> tabs 1,+1,+2,+3,+5,+8,+13,+21,+34,+55,+89

You're just telling fibs again.

--
\ "Programs must be written for people to read, and only |
`\ incidentally for machines to execute." —Abelson & Sussman, |
_o__) _Structure and Interpretation of Computer Programs_ |
Ben Finney

== 3 of 4 ==
Date: Sat, Feb 27 2010 4:20 pm
From: ike@localhost.claranet.nl (Ike Naar)

In article <4b8924a6$0$22939$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>ike@localhost.claranet.nl (Ike Naar) writes:
>> if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 &&
>> sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 &&
>> needs_processing(color)) {
>> compute_volume(length, width, height);
>> compute_something_else(price, weight);
>> }
>
>>vs.
>
>> if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 &&
>> sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 &&
>> needs_processing(color))
>> {
>> compute_volume(length, width, height);
>> compute_something_else(price, weight);
>> }
>
>>In the first case, it is hard to see where the condition ends
>>and where the body starts. In the second case it's obvious.
>>Don't you think that the opening brace on its own line here improves
>>the readability?
>
>I call a strawman; a proper c-style will not allow the first form;
>e.g., at Sun our style requires this form:
>
> if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 &&
> sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 &&
> needs_processing(color)) {
> compute_volume(length, width, height);
> compute_something_else(price, weight);
> }

I don't think your strawman call is justified.
My "first case" is the output of (gnu) "indent -kr".

== 4 of 4 ==
Date: Sat, Feb 27 2010 6:43 pm
From: Jonathan de Boyne Pollard

>
>
> Cost of a line feed is the same as the cost of a space character
>
That is only the case when one's terminal is set to NL0 mode and isn't
set to ONLCR or ONLRET modes, or it is set to both CR0 and NL0 modes.

==============================================================================
TOPIC: Edward Nilges' lie
http://groups.google.com/group/comp.lang.c/t/14c6f4a4afe68f60?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 27 2010 3:40 pm
From: Walter Banks

Richard Heathfield wrote:

> I suppose it's not impossible. It
> goes like this:
>
> "Dear Mr Heathfield

snipped

Now you have done it, I have blown coffee all over
my keyboard :)

w..

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

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

== 1 of 5 ==
Date: Sat, Feb 27 2010 3:46 pm
From: Ian Collins

Richard Heathfield wrote:
> spinoza1111 wrote:
>
>> Yes, I know less about C than you, but you're not even a programmer,
>> and no amount of deception will refute this.
>
> You are now on record as claiming that you know even less about C than
> someone whom you don't even recognise as a programmer, and no amount of
> deception will refute this.

Classic! I think I'll print that one for posterity. Thank you Richard.

--
Ian Collins

== 2 of 5 ==
Date: Sat, Feb 27 2010 8:10 pm
From: spinoza1111

On Feb 28, 7:46 am, Ian Collins <ian-n...@hotmail.com> wrote:
> Richard Heathfield wrote:
> >spinoza1111wrote:
>
> >> Yes, I know less about C than you, but you're not even a programmer,
> >> and no amount of deception will refute this.
>
> > You are now on record as claiming that you know even less about C than
> > someone whom you don't even recognise as a programmer, and no amount of
> > deception will refute this.

Yes, I know less about C than you, and you're no programmer, Richard.
That is the truth. You have memorized facts but you simply cannot code
properly, and your linked list proved it.

Don't feel too bad. Your buddy Seebach is even less of a programmer.
Many other people know details about the syntax and even semantics of
programming or natural languages but are not programmers of the one,
nor can function in the other. There were many college professors of
Chinese who were unable to travel to mainland China between 1949 and
1980 who could not at first function in Beijing or Shanghai Puthongua
after China opened after 1980, and their are no genuine speakers of
Latin, are there.

Furthermore, a programmer would be in my view able to learn object
oriented programming apart from rote anti-OO sloganeering, and you've
had twenty years to do so, and you haven't.

Bill Gates, who wasn't a programmer or at least not a very good one,
said it well nonetheless to Susan Lammers for "Programmers at Work" in
1986. He said he wanted developers who would, when confronted with the
need to learn a new programming language, take the manual home, read
it in the evening, and start work the next morning.

The only place one gets this ability is through university study (or
in exceptional cases autodidact study) of computer science independent
of instantiation in code, and your linked list folly proves you don't
have this.

Forest and trees. You're so full of shit about details that you cannot
think outside the box.
>
> Classic! I think I'll print that one for posterity. Thank you Richard.
>
> --
> Ian Collins

== 3 of 5 ==
Date: Sat, Feb 27 2010 8:13 pm
From: spinoza1111

On Feb 28, 6:11 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-27, Julienne Walker <happyfro...@hotmail.com> wrote:
>
> > On Feb 27, 11:52 am,spinoza1111<spinoza1...@yahoo.com> wrote:
> >> Which some brilliant people at Sun and Microsoft have done. Moore's
> >> Law should take care of the rest. Why is C not given a hero's funeral?
> > For the same reason COBOL hasn't: there's a great deal of existing
> > code out in the wild.
>
> Not just that. There are problems where Moore's Law isn't enough, because
> ANY improvement in speed is pretty worthwhile, and where native C tends
> to win.
>
> Kernels, for instance.

Perhaps, although C is by no means the only language in which to write
a "kernel".

But you're not qualified to infer from the fact that C MIGHT be the
best choice for a "kernel" to the silly idea that it's a good idea to
write C for silly little filters with bugs in them,
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 4 of 5 ==
Date: Sat, Feb 27 2010 8:28 pm
From: spinoza1111

On Feb 28, 4:03 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> On Feb 27, 11:52 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Feb 27, 12:27 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> > > On Feb 26, 3:00 am,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > > On Feb 26, 3:36 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> > > > > On Feb 25, 1:46 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > > > > On Feb 25, 10:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> > > > > > > spinoza1111wrote:
>
> > > > > > > > Look, buddy, your ridiculous linked list can
> > > > > > > > unpredictably bring systems down if it is passed large objects.
>
> > > > > > > Feel free to demonstrate how. I'm reasonably sure that I've catered for
> > > > > > > that possibility using failure codes to indicate where memory is not
> > > > > > > available to store an object, but do you have a counter-example?
>
> > > > > > I saw no try catch in your code.
>
> > > > > Probably because there's no such construct in portable C. You can
> > > > > simulate exceptions using standard C, but it gets ugly very quickly.
>
> > > > Pity.
>
> > > Not really. C isn't a language that lends itself to proper exception
> > > support because there are too many points where exceptions fall flat.
> > > One can see the problems by looking at C++. C++ exceptions are useful
> > > to a point, but in my opinion they're not nearly as beneficial as they
> > > would be if C++ integrated them more fully into the language (throwing
> > > an exception on out of bounds array indexing, for example) and had
> > > native garbage collection.
>
> > > By the time you plug the holes, you'll have something more like Java
> > > or C#.
>
> > Which some brilliant people at Sun and Microsoft have done. Moore's
> > Law should take care of the rest. Why is C not given a hero's funeral?
>
> For the same reason COBOL hasn't: there's a great deal of existing
> code out in the wild. In many cases, it makes no sense to upgrade
> because there's little or no benefit to justify the time, cost, and
> risk of rewriting working code in a different language simply because
> the current language is outdated.
>
> > > I agree that copying large objects may be problematic, especially with
>
> > It IS.
>
> > > an extra malloc call. I don't agree that it's a deal breaker. I'm not
> > > the only one who's suggested that copying a pointer to the data rather
> > > than the data itself is one way to get the effect of referencing with
> > > a copying linked list. You just need to be aware of your memory
> > > management (as one should be), and avoid unnecessary copies on the
> > > client side.
>
> > One irritating characteristic of some of your replies is the sudden
> > entry of terminology such as "client side" which doesn't necessarily
> > apply in the abstract problem.
>
> I'm making the distinction between a reusable library and code that
> uses the library (the client). This distinction is important because
> while a library will have consistent performance attributes, the
> client can vary wildly. However, the two must work together to be of
> any use. Without clients, a reusable library is pointless, and without
> the library, the problem is no longer abstract. We would need to
> consider the problem domain of a concrete application to make educated
> decisions about performance.

No, that's not the case here, and the view that there is an extra load
of "problem domains" over and above computer science, applied common
sense, the law, and compassion for others has created the software
crisis, in my view.

The problem is that there are no "first principles" of corporate
management. Peter Drucker thought he knew them for the same reason
Alan Greenspan thought he knew how to manage the economy, and both, at
the end of the day, admitted defeat.

This is why I think programmers should regard themselves, not as the
slave-servants of corporate executives, but as the assistants to
workers and the people.

Specifically, a programmer who's programming a machine tool should
regard the operator as his user; the programmer whose developing a
banking application should regard the teller and the customer on the
other side of the grille as his most important users. This will sound
strange to American programmers, but in fact, Ole Johan Dahl developed
object oriented code in Denmark in order to best document and build
the systems he developed for Danish workers, because in Danish law
such systems had to have input from labor unions.

The superstition that there is something magic about "requirements"
and that only a special priestly class of failed programmers, promoted
into "analysts", has created too much pressure on programming time as
the analyst's dried voices whisper amongst themselves about
"requirements". The "analysts" are corrupted by the power struggle
amongst executives for control.
>
> > The only problem, in fact, that I see in your texts is a corporate
> > vice: being even handed, overly interested in sacrificing first
> > principles to "trade offs", and giving equal time to evil.
>
> I don't see being even handed as a vice. Impartially judging every
> option and choosing the best among them produces the best results. If
> you're biased, you can easily miss options or opportunities that may
> be superior. Classifying things as "evil" is a fantastic way to close
> doors on yourself.

New Age psychobabble, albeit literally expressed, of the sort used to
discipline people who in fact know what they are doing.

Look, despite the fact that I'm smarter than many people here, I have
a track record. I spoke the truth, and people don't like it, so I'm
"it". Being even-handed in my case just perpetuates an injustice, and
I need affirmative action at this point.

That may sound self-serving, and it is, for let us not speak falsely
now. The point is that no situation is a level playing field: to make
a level soccer field in my community here in China, which is a
mountainous island, the village elders had to pave a small area on the
waterfront, and I regularly see the kids banging their knees. The
"level playing field" is a fantasy of justice, to which people in the
US Midwest or at Harrow are addicted, since they have big football
fields in the former and green grassy swards in the other. In
Bangladesh, kids play "football" in the street using the street's
rules, and they know what's being done to them.

The time is past for a level playing field. I don't accept Richard's
solution save as an option.

== 5 of 5 ==
Date: Sat, Feb 27 2010 9:01 pm
From: Mark L Pappin

Richard Heathfield <rjh@see.sig.invalid> writes:

> Nick Keighley wrote:
>> On 23 Feb, 10:00, Richard Heathfield <r...@see.sig.invalid> wrote:
>>> Nick Keighley wrote:
>>>> On 22 Feb, 22:29, "Bill Cunningham" <nos...@nspam.invalid> wrote:
>>>>> "Richard" <rgrd...@gmail.com> wrote in message
>>>>> news:bnga57-5i8.ln1@news.eternal-september.org...
>>
>>>>>> That doesnt wash with me.
>>>>>> Putting the decrement in the body makes it less clear.
>>>>>> If a post decrement is too clever for the reader then so is using C.
>>>>> Use a debugger.
>>>> no, don't
>>>> a debugger is not the right tool to learn what C constructs do
>>> I'm *reasonably* sure he was joking - yanking Richard NoName
>>> MyHammerIsADebuggerAndEveryProblemIsANail Riley's chain a little.
>> I didn't think Bill was that witty.
>
> Neither did I. Hence the **s around "reasonably".

It's possible that BC has just blown his cover.

mlp

==============================================================================
TOPIC: What is wrong with my program?
http://groups.google.com/group/comp.lang.c/t/96917c25ae9f8d02?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 27 2010 3:56 pm
From: ike@localhost.claranet.nl (Ike Naar)

In article <4b88ca69$1_1@news.tm.net.my>, Tadpole <tskhoon@streamyx.com> wrote:
>Hi,
>I am trying to print 5 unique random numbers 0 to 4. But each time I
>print, I get funny result. What is wrong with my program? Please see
>below.

You might also have a look at clc faq question 13.19:

http://c-faq.com/lib/shuffle.html

== 2 of 2 ==
Date: Sat, Feb 27 2010 8:56 pm
From: "Tadpole"

> You might also have a look at clc faq question 13.19:
>
> http://c-faq.com/lib/shuffle.html

Your suggestion is absolutely brilliant.
It exactly solves my problem with only just a few programming lines. As
shown below: I shuffle 20 times.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main ()
{ int A[]= {0,1,2,3,4};
srand (time(NULL));
int x,y,z;
for (int i=0; i<20 ;i++)
{ x =rand()%5;
y =rand ()%5;
printf ("%d %d \n",x,y);
z= A[x];
A[x]=A[y];
A[y]=z;
}
printf ("\n");
for (int i=0; i<5; i++)
printf ("A[%d]= %d\n",i,A[i]);
return 0;
}

Is there one "include" statement that I can write to substitute the 3 "
#include " statement in the header?
Meaning #include < XXX.h > where XXX represent the statement I am
searching for?
Rgds,
Khoon

==============================================================================
TOPIC: Access to common field in structs
http://groups.google.com/group/comp.lang.c/t/41a1aee54949480d?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 27 2010 4:09 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <4B8930BD.18D2@mindspring.com>, pete <pfiland@mindspring.com> writes:
> Ersek, Laszlo wrote:
>>
>> In article <9kSZowG9B28b@ludens>, lacos@ludens.elte.hu (Ersek, Laszlo) writes:

>> > C99 6.7.2.1 "Structure and union specifiers", p13:
>> >
>> > ----v----
>> > Within a structure object,
>> > the non-bit-field members and the units in
>> > which bit-fields reside have addresses that increase in the order in
>> > which they are declared. A pointer to a structure object, suitably
>> > converted, points to its initial member (or if that member is a
>> > bit-field, then to the unit in which it resides),
>> > and vice versa. There
>> > may be unnamed padding within a structure object, but not at its
>> > beginning.
>> > ----^----

>> > C99 6.3.2.3 "Pointers", p7:
>> >
>> > ----v----
>> > A pointer to an object or incomplete type
>> > may be converted to a pointer
>> > to a different object or incomplete type.
>> > If the resulting pointer is
>> > not correctly aligned [...] for the pointed-to type, the behavior is
>> > undefined. Otherwise, when converted back again, the result shall
>> > compare equal to the original pointer. [...]
>> > ----^----
>>
>> Looking at these two passages simultaneously, Dominik may be right,
>> because the upper citation talks about a pointer to a structure
>> *object*, and that is different from a pointer to an incomplete type,
>
> I disagree with that.
> A pointer to void, is a pointer to an incomplete type.
> A pointer to void, can point to a struct object.

I like this. Perhaps:

- when 6.7.2.1p13 says "pointer to a structure object", it means that
the memory pointed to by the pointer actually holds a structure object,

- while when 6.3.2.3p7 says "pointer to an (object|incomplete) type",
ie. the word "object" is not standalone but part of the expression
"object type", it talks about the type of the pointer.

Or something like that.

Thanks,
lacos

== 2 of 2 ==
Date: Sat, Feb 27 2010 7:13 pm
From: pete

Dominik Zaczkowski wrote:
>
> pete <pfiland@mindspring.com> writes:
> >> In article <9kSZowG9B28b@ludens>, lacos@ludens.elte.hu (Ersek, Laszlo) writes:
> >> > In article <87mxyv82su.fsf@kraina-oz.ath.cx>, Dominik Zaczkowski <dmz@pro.wp.pl> writes:
>
> <SNIP>
>
> >> >> [If] compiler can assume that pointers to different types point to
> >> >> different memory locations,
> >> >
> >> > I don't think this could be asserted in general.
> >
> > It most definitely can' be asserted.
> >
> > signed char a;
> > signed char *b = &a;
> > unsigned char *c = (signed char *)&a;
> >
> > Both (b) and (c) point to the same byte.
> >
>
> I said "If compiler can assume". In above example it can't but in case
> of different struct types?
>
> If it can, then I see no way how this could be OK:
>
> #include "new_a.h"
>
> struct A;
> struct B {
> int a, b;
> };
>
> struct A *aptr = new_A();
> struct B *bptr = (struct B *)aptr;
>
> Or maybe compiler is permitted to assume that struct pointers with
> different types point to different
> locations only when both struct types
> are complete and B is not first member of A?

If A and B are different complete struct types,
then pointers to each type
can both point to the same object allocated by malloc,
as long as the object is big enough.

--
pete

==============================================================================
TOPIC: Another doubleunderscore thingy
http://groups.google.com/group/comp.lang.c/t/3879f22a8a1b80ee?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Feb 27 2010 6:08 pm
From: markhobley@hotpop.donottypethisbit.com (Mark Hobley)

In comp.os.linux.development.apps Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
> Right. That is just as messy as __dead. I think I will just delete the tag.

Right I have found another doubleunderscore thingybob. This time __progname:

void
usage(void)
{
extern char *__progname;
(void)fprintf(stderr, "usage: %s [-itw] file ...\n", __progname);
exit(1);
}

This was easier to find in google than the last one. I stumbled across:

http://stackoverflow.com/questions/273691/using-progname-instead-of-argv0

This tells me that __progname is a bsdism and getopt() modifies argv[],
which is not available outside of main(). I guess that I need to somehow
capture argv[0] on entry to main. I guess that the following is a fixup for
this:

extern char *progname;

int
main(int argc, char *argv[])
{
extern char *progname;
progname=argv[0];
blah blah blah
}

void
usage(void)
{
extern char *progname;
(void)fprintf(stderr, "usage: %s [-itw] file ...\n", progname);
exit(1);
}

Does that look right?

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

== 2 of 3 ==
Date: Sat, Feb 27 2010 9:08 pm
From: markhobley@hotpop.donottypethisbit.com (Mark Hobley)

In comp.os.linux.development.apps Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:

> extern char *progname;

Hmmm. It's not external now though. I changed this to:

char *progname;

When I compile, I get an error:

getname.c: In function 'main':
getname.c:96: error: 'optind' undeclared (first use in this function)
getname.c:96: error: (Each undeclared identifier is reported only once
getname.c:96: error: for each function it appears in.)

That error looks right to me: 'optind' is undeclared. I wonder if this is an
error in the original bsd code, or whether optind becomes defined in the
bsd versions of the header files, or the optind becomes defined when the bsd
compiler is used.

The headers are:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libgen.h>

The specification says:

SYNOPSIS

#include <unistd.h>

int getopt(int argc, char * const argv[], const char *optstring);
extern char *optarg;
extern int optind, opterr, optopt;

Maybe optind is defined in unistd.h

I added the declaration to the top of the file, and now I get an error:

getname.c:(.text+0x304): undefined reference to `strlcat'

There is a string.h file, so I don't know what is going on there.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

== 3 of 3 ==
Date: Sat, Feb 27 2010 9:17 pm
From: Ian Collins

Mark Hobley wrote:
> In comp.os.linux.development.apps Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
>
>> extern char *progname;
>
> Hmmm. It's not external now though. I changed this to:
>
> char *progname;
>
> When I compile, I get an error:
>
> getname.c: In function 'main':
> getname.c:96: error: 'optind' undeclared (first use in this function)

Then you haven't included the header where it is declared.

> getname.c:96: error: (Each undeclared identifier is reported only once
> getname.c:96: error: for each function it appears in.)
>
> That error looks right to me: 'optind' is undeclared. I wonder if this is an
> error in the original bsd code, or whether optind becomes defined in the
> bsd versions of the header files, or the optind becomes defined when the bsd
> compiler is used.
>
> The headers are:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <libgen.h>

Well given the synopsis below, you are missing <unistd.h>.

> The specification says:
>
> SYNOPSIS
>
> #include <unistd.h>
>
> int getopt(int argc, char * const argv[], const char *optstring);
> extern char *optarg;
> extern int optind, opterr, optopt;
>
> Maybe optind is defined in unistd.h

No, it may be declared there, but it will be defined in a library source
file.

> I added the declaration to the top of the file, and now I get an error:
>
> getname.c:(.text+0x304): undefined reference to `strlcat'
>
> There is a string.h file, so I don't know what is going on there.

It will probably be declared in <strings.h>, see the man page.

--
Ian Collins

==============================================================================
TOPIC: scanf
http://groups.google.com/group/comp.lang.c/t/b17467b72cf67b35?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 27 2010 6:17 pm
From: "osmium"

Bill Cunningham wrote:

> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:ln1vg6v5ak.fsf@nuthaus.mib.org...
>
> [snip]
>
>> Bill, either stop using Outlook Express or find out how to get it to
>> quote properly.
>
> I thought for sure that I have it down correct manually.

Did you know that you can see even what *you* have posted? Amazing, but
true. Look at the message containing your answer to Malcolm. It does not
distinguish between what Malcolm said and what you said. See the problem?

Malcolm posted via Google, that's the origin of the problem. Use the
Quotefix "version" of OE when responding to people who post via Google.

==============================================================================
TOPIC: Plan 9's c compiler
http://groups.google.com/group/comp.lang.c/t/110a62f10b04cea0?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 27 2010 2:26 pm
From: "Bill Bonde {Colourless green ideas don't sleep furiously)"

Dan C wrote:
>
> On Fri, 26 Feb 2010 01:12:23 -0700, Phred Phungus wrote:
>
> > William Ahern wrote:
> >> Phred Phungus <Phred@example.invalid> wrote:
> >>> I've been reading up on the whole Plan 9 thing. Links here:
> >> <snip>
> >>> My question is whether I can get Pcc without having to create a Plan 9
> >>> partition.
> >>
> >> Do you want to cross-compile or are you merely interested in the Plan 9
> >> additions to the C language?
> >>
> >> C99 includes designated initializers--similar to "initialization
> >> indexes" (GCC supports both syntactical forms)--and compound
> >> literals--"structure display". Many compilers, including GCC, support
> >> anonymous unnamed structure and union members. MSC, and GCC in
> >> MSC-compability mode, support tagged unnamed members as well.
> >>
> >>
> > I'll cross compile sometime after I have Hello plan 9 world
> > as output.
> >
> > One thing I like about a dual-booting computer is that I have the
> > 'merican OS, windows, and the hippy OS, ubuntu as differing platforms
> > just to see how code runs.
> >
> > Part of my motivation is that gcc doesn't work for me effectively on
> > windows. I was hoping plan 9 could expose why I can use outlook express
> > but not differing combinations of gnu development tools.
>
> Bugger off, Win-droid.
>
Dan C's a real salt of the earth type.

--
"It is illuminating for purposes of reflection, if not for
argument, to note that one of the greatest 'fictions' of our
federal system is that the Congress exercises only those powers
delegated to it, while the remainder are reserved to the States or
to the people. The manner in which this Court has construed the
Commerce Clause amply illustrates the extent of this fiction.",
Hodel v. Virginia Surface Mining, 452 U.S. 264, 307 (1981)

== 2 of 2 ==
Date: Sat, Feb 27 2010 8:37 pm
From: Dan C

On Sat, 27 Feb 2010 11:41:09 +0200, Phil Carmody wrote:

> Andy <nospam@> writes:
>> Phil Carmody wrote:
>>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>> On 2/26/2010 8:50 AM, Dan C wrote:
>>>>> [30 lines of quote, followed by this enlightening message:] Bugger
>>>>> off, Win-droid.
>>>>
>>>> The poster's signature advertises something calling itself
>>>> "The Usenet Improvement Project," whose stated goal is "to make
>>>> Usenet participation a better experience." R-i-i-i-g-h-t.
>>>
>>> His .sig pointed to http://twovoyagers.com/improve-usenet.org/
>>> However, the real usenet improvement project has URL
>>> http://improve-usenet.org/ accept no immitations, middlemen, or
>>> proxies.
>>
>> No.
>>
>> http://improve-usenet.org leads to a page saying "This account has been
>> suspended".
>>
>> Blinky (who ran the site) died about a year ago. The twovoyagers.com
>> site was put together shortly after and retains most of the original
>> site in his memory.
>
> Yikes; mouth meet foot, or feet.

Public spanking completed.

Bugger off, doofus. You're way overmatched.

--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as the Facehugger impregnated him.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Thanks, Obama: http://brandybuck.site40.net/pics/politica/thanks.jpg

==============================================================================
TOPIC: Error with threads opening files
http://groups.google.com/group/comp.lang.c/t/2dc4e1c41436509b?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 27 2010 7:20 pm
From: "lancer6238@yahoo.com"

Hi all,

I'm using C and pthread on a Linux machine, and I'm having trouble
parallelizing a program.

I'm basically trying to take in a folder of data files, divide them
into groups, each group handled by a thread, and run a function on
each of the data file.

The way I'm doing this is I have a global char **filename variable,
where filename[i] = filename of a data file. In the main function,
I'll read in the filenames of all the data files (minus "." and "..")
using scandir and put them in the filename variable. Then 4 (arbitrary
number) threads are created each calling the Process function. In
Process(), each thread only opens (using a FILE *fin declared in
Process()) and works on a portion of the data files using a
start_index and an end_index. For example, if there are 100 files,
then each thread will handle filename[0] to filename[24], filename[25]
to filename[49], filename[50] to filename[74] and filename[75] to
filename[99] respectively. After they're done, there is a pthread_join
in main() for all 4 threads.

I have checked that the filenames have been stored correctly, both in
main() and Process(). However, I keep getting segmentation fault here,
in Process():

for (i = start_index, i <= end_index ; i++)
fin = fopen(filename[i], "rb"); <--- Seg fault

I don't really get why there should be an error since none of the
threads are trying to open the same file.

Please advise.

Thank you.

Regards,
Rayne

== 2 of 2 ==
Date: Sat, Feb 27 2010 7:31 pm
From: Ian Collins

lancer6238@yahoo.com wrote:
> Hi all,
>
> I'm using C and pthread on a Linux machine, and I'm having trouble
> parallelizing a program.
>
> I'm basically trying to take in a folder of data files, divide them
> into groups, each group handled by a thread, and run a function on
> each of the data file.
>
> The way I'm doing this is I have a global char **filename variable,
> where filename[i] = filename of a data file. In the main function,
> I'll read in the filenames of all the data files (minus "." and "..")
> using scandir and put them in the filename variable. Then 4 (arbitrary
> number) threads are created each calling the Process function. In
> Process(), each thread only opens (using a FILE *fin declared in
> Process()) and works on a portion of the data files using a
> start_index and an end_index. For example, if there are 100 files,
> then each thread will handle filename[0] to filename[24], filename[25]
> to filename[49], filename[50] to filename[74] and filename[75] to
> filename[99] respectively. After they're done, there is a pthread_join
> in main() for all 4 threads.
>
> I have checked that the filenames have been stored correctly, both in
> main() and Process(). However, I keep getting segmentation fault here,
> in Process():
>
> for (i = start_index, i <= end_index ; i++)
> fin = fopen(filename[i], "rb"); <--- Seg fault
>
> I don't really get why there should be an error since none of the
> threads are trying to open the same file.
>
> Please advise.

The real problem is probably in the code you haven't posted. Post a
(short if possible) complete example.

--
Ian Collins

==============================================================================
TOPIC: What is the explanation?
http://groups.google.com/group/comp.lang.c/t/43491a16c11fd4e0?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 27 2010 7:33 pm
From: nobody@xmission.com (Scott)

On Sat, 27 Feb 2010 22:39:26 +0000 (UTC), in comp.lang.c, Willem
<willem@snail.stack.nl> wrote:

>Tadpole wrote:
>)
>) "Richard Delorme" <abulmo@nospam.fr> wrote in message
>) news:4b88d21a$0$17882$ba4acef3@reader.news.orange.fr...
>)> Le 27/02/2010 07:16, Tadpole a ?crit :
>)>
>)> [...]
>)>> if ( x !=( 7||8))
>)>
>)>> Question 1 : Why is 1 missing here?
>)>
>)> The value of (7||8) is 1.
>)>
>)> --
>)> Richard
>)
>) Hi Richard,
>) Kindly explain why or how (7||8) is 1 ?
>) I am amazed.
>
>What do you expect the value of (7||8) to be ?

I would not expect it to be 1. I would just expect it to not be zero.

== 2 of 2 ==
Date: Sat, Feb 27 2010 8:43 pm
From: "Tadpole"

>>)
>>) Hi Richard,
>>) Kindly explain why or how (7||8) is 1 ?
>>) I am amazed.
>>
>>What do you expect the value of (7||8) to be ?
>
> I would not expect it to be 1. I would just expect it to not be zero.

No. The answer is always 1. . I have tested it and it gives me 1 and no
other number.

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

== 1 of 1 ==
Date: Sat, Feb 27 2010 8:42 pm
From: spinoza1111

On Feb 28, 1:20 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:425c7af0-8f2a-4394-8e95-92492bb9b19f@f17g2000prh.googlegroups.com...
> On Feb 27, 1:13 am, "io_x" <a...@b.c.invalid> wrote:
>
>
>
>
>
> > "spinoza1111" ha scritto nel
> > messaggionews:210fec94-aa97-4b77-a239-668539100ad9@c37g2000prb.googlegroups.com...
> > On Feb 22, 4:06 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote:> In
> > article
> > <06317ad6-cd11-48e7-80db-3341ef3a1...@b9g2000pri.googlegroups.com>,
>
> > > while(*ptrIndex1)
> > > {
> > > ptrIndex0 = ptrIndex1;
> > > while (-1)
> > > {
> > > // --- Check for (one character) handle
> > > for(;
> > > *ptrIndex1 && *ptrIndex1 != *strTarget;
> > > ptrIndex1++);
> > > // --- Check for complete match while remembering the
> > > // --- last position of the handle
>
> > > yes this "for" seems run good
> > > but remember the last position of hadle means memory, means to use
> > > malloc or get
> > > memory from the stack: what about there are 1.000.000s of "matchs"
>
> > There's no problem, I think. The last position of the handle is used
> > and thrown away. If there are millions of matches, there IS a
> > "problem". This is a large linked list of unmatching segments.
>
> > However, Willem's code and mine both demonstrate, I think, the minimal
> > storage complexity of the problem. It appears to me that most other
> > solutions lazily do a big malloc, and some of them may even forget to
> > free() what isn't needed.
>
> Well, IMVHO, your solution is fairly inefficient wrt storage because it
> dynamically allocates a linked list node via `malloc()' for every darn
> match. For instance, the following:
>
> replace("abababababababababa", "a", "b", &x);
>
> gives me 11 calls to `malloc()', 10 calls to `free()', plus one `free()' I
> have to do in order to reclaim the returned string. Okay, this means that
> you are using 160 bytes (or perhaps 240 on a 64-bit system) of dynamically
> allocated storage to hold the linked-list for a source string that is only
> 19 characters long.

Good point. You present a string which results in a linked list of
addresses of characters as a potential worst case, and you're right.

This could occur in genetics applications with which Malcolm seems to
work.

And there are many things we can do about this problem. Sure, each
linked list node could in general hold not a pointer and a length, but
an array of pointers and lengths of fixed size as a cache.

Or we could throw out linked lists and return instead an array of
pointers and lengths. We could use run length encoding in this array,
whose element would look like this:

struct changes { int repeatMe; char *p; int len };

But soft. The problem is becoming one of representing strings in the
best way possible. The string in your example is itself "inefficient"
since it could be represented more compactly using a repeat count. You
pass my solution weird data, yes, its performance suffers.

And yes, we're somewhat responsible for not having surprise
performance issues for unexpected data. Those of us who are real
programmers lose beauty sleep over this, unlike Richard Heathfield,
who doesn't seem to care that in his "reusable" linked list a large
amount of data will be a performance hog.

But now you're talking about how best to represent strings, which is
best done not in C but in an OO language, because inside the object we
can represent the string how the hell we want.

>
> Why not at least do a simple stack-based region allocator for linked-list
> nodes and switch over to `malloc()' when that is exhausted? Or attempt to
> amortize everything by letting a single list node hold multiple matches?
>
> [...]

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

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

Saturday, February 27, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts