twitter: comp.lang.c - 24 new messages in 6 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* usage of size_t - 11 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* C99 is widely used! - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/0ba05b02a32efc0a?hl=en
* Stylistic questions on UNIX C coding. - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* substring finding problem! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
* Plan 9's c compiler - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/110a62f10b04cea0?hl=en
* tcp server: how to send message to all the connected client at every time
interval - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/a222c6094f2760ff?hl=en

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

== 1 of 11 ==
Date: Thurs, Feb 25 2010 4:32 pm
From: Richard Heathfield

Chris M. Thomasson wrote:

<snip>

>
> Humm... I may me misunderstanding you, buy exactly why do the objects
> need to be stored elsewhere? I mean, the list already stores a reference
> to the object and that's good enough for me.

If that object isn't stored somewhere, to what does the reference refer?
First rule of objects: Everything Has To Be Somewhere.

> For instance, where am I
> using extra storage to "store objects" in the following program:
>
>
> http://clc.pastebin.com/3ymseiDB

Line 78.

<snip>

--
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

== 2 of 11 ==
Date: Thurs, Feb 25 2010 4:47 pm
From: "Chris M. Thomasson"

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:FY-dnVOZr63mixrWnZ2dnUVZ8qti4p2d@bt.com...
> Chris M. Thomasson wrote:
>
> <snip>
>
>>
>> Humm... I may me misunderstanding you, buy exactly why do the objects
>> need to be stored elsewhere? I mean, the list already stores a reference
>> to the object and that's good enough for me.
>
> If that object isn't stored somewhere, to what does the reference refer?
> First rule of objects: Everything Has To Be Somewhere.
>
>> For instance, where am I using extra storage to "store objects" in the
>> following program:
>>
>>
>> http://clc.pastebin.com/3ymseiDB
>
> Line 78.

I think I was totally misunderstanding the issue Richard!

== 3 of 11 ==
Date: Thurs, Feb 25 2010 4:56 pm
From: "Chris M. Thomasson"

"Seebs" <usenet-nospam@seebs.net> wrote in message
news:slrnhoe3n5.nj2.usenet-nospam@guild.seebs.net...
> On 2010-02-25, Chris M. Thomasson <no@spam.invalid> wrote:
>> Humm... I may me misunderstanding you, buy exactly why do the objects
>> need
>> to be stored elsewhere?
>
> If they don't, where does the pointer point?
>
>> I mean, the list already stores a reference to the
>> object and that's good enough for me. For instance, where am I using
>> extra
>> storage to "store objects" in the following program:
>
> "Extra" meaning "in addition to the list objects".
[...]

Okay, but how would you implement my sample program using nothing but
value-based containers? Assume that you are forced to work with a container
library that provided nothing but value-based containers. Each object is
stored on N lists and I do not want each node to have a separate copy of an
object.

== 4 of 11 ==
Date: Thurs, Feb 25 2010 4:58 pm
From: "Chris M. Thomasson"

Fair enough. But how would I create that program using nothing but
value-based containers?

== 5 of 11 ==
Date: Thurs, Feb 25 2010 5:04 pm
From: Richard Heathfield

Chris M. Thomasson wrote:
<snip>

> Okay, but how would you implement my sample program using nothing but
> value-based containers?

Step 1: using what we are now calling a "value-based" container, read in
the data, and pass a pointer to it, and its size, to the container add
function, e.g. array_add(&array, &foo, sizeof foo);

Step 2 would go something like this:

n = array_count(array);
for(i = 0; i < n; i++)
{
p = array_fetch(array, i);
list_add(&list, &p, sizeof p);
}

--
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

== 6 of 11 ==
Date: Thurs, Feb 25 2010 5:05 pm
From: Richard Heathfield

Chris M. Thomasson wrote:

<snip>

> Fair enough. But how would I create that program using nothing but
> value-based containers?

See my earlier reply.

--
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

== 7 of 11 ==
Date: Thurs, Feb 25 2010 5:53 pm
From: "Chris M. Thomasson"

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:dqudnev74ty3gxrWnZ2dnUVZ8nGdnZ2d@bt.com...
> Chris M. Thomasson wrote:
> <snip>
>
>> Okay, but how would you implement my sample program using nothing but
>> value-based containers?
>
> Step 1: using what we are now calling a "value-based" container, read in
> the data, and pass a pointer to it, and its size, to the container add
> function, e.g. array_add(&array, &foo, sizeof foo);
>
> Step 2 would go something like this:
>
> n = array_count(array);
> for(i = 0; i < n; i++)
> {
> p = array_fetch(array, i);
> list_add(&list, &p, sizeof p);
> }

Okay. I am curious as to how the list nodes internal structure would look?
It seems like you could end up wasting some space in this case. For
instance, if the node was like:

struct node
{
struct node* next;
void* data;
size_t size;
};

Is the `node::size' member not wasted space if we only store a pointer to an
object? Also, would the container have to actually allocate space for a
pointer? Humm... Would the container have to make two allocations, 1 for the
node, and 1 for the data in this case?

Also, if this was C99:

struct node
{
struct node* next;
char data[];
};

Would there be alignment issues if you stored something that was not a char?

== 8 of 11 ==
Date: Thurs, Feb 25 2010 6:05 pm
From: Richard Heathfield

Chris M. Thomasson wrote:
<snip>

> Okay. I am curious as to how the list nodes internal structure would
> look? It seems like you could end up wasting some space in this case.

The amount of storage you need depends on how your list is designed. For
example, if all your objects are the same size you might decide to keep
that information outside the list - your program just "knows" (e.g.
you've only stored foos in there, and you know how big a foo is). Or you
might decide to have that information stored in a meta-node that "owns"
the list. But if your list can store heterogenous objects, AFAIAA you
have no real choice but to store the size in each node.

To cut a long reply short, there are many decision points in the design
of a linked list, and many of those decisions involve trade-offs. In CU
I just showed one possible design among many. If memory is at an
absolute premium, clearly you'll take a different approach than someone
who's awash with RAM; he will have different priorities to you.

<snip>

--
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

== 9 of 11 ==
Date: Thurs, Feb 25 2010 7:20 pm
From: Kelsey Bjarnason

[snips]

On Thu, 25 Feb 2010 14:48:00 -0800, Keith Thompson wrote:

> If two pointers that point to the same thing don't compare equal, then
> the implementation is non-conforming. C99 6.5.9p6:
>
> Two pointers compare equal if and only if both are null pointers,
> both are pointers to the same object [...]
>
> (The "[...]" deals at some length with function pointers and pointers
> just past the end of objects.)
>
> I suppose I'm not surprised that a C compiler that deals with the
> various memory models might not be completely conforming.

In the one compiler (at least one version of Turbo C) where I encountered
this, it was explained as a simple tradeoff between performance and
consistency.

Essentially, you had three "flavours" of pointers: near, far and huge.
An unadorned pointer (eg void *p) was generally a "near" pointer. Near
pointers were limited to a single 64k segment, and thus did not suffer
the need for normalization.

Huge pointers were full (32-bit?) pointers, ranging over the entire
usable address space, but in a manner such that segment wrapping,
comparison and the like weren't an issue - comparisons worked, increments
past segment boundaries worked, etc, etc, etc.

The real screwball was the "far" pointer. Basically, it worked like a
"near" pointer, but included a segment value. In essence, it was a near
pointer, but in a different segment of memory than the default near
pointers. This allowed allocating memory outside the scope of a single
64K segment, while retaining most of the performance of a near pointer...
but led to the inconsistency that due to the fact multiple segment:offset
pairs could refer to the same address, comparing far pointers was not
guaranteed to produce expected results.

Any normal C code thrown at the compiler - eg code using plain "void *p"
- would do the right thing. It was, as I recall, only the decorated
"far" pointers which suffered the comparison failure issue.

They also suffered wraparound. Eg if a pointer p pointed at the last
byte of a segment s, then p++ would result in an address of s:0 rather
than s+1:0. Huge pointers incremented to s+1:0.

Again, so nice not to have to deal with this crap anymore. Indeed, once
I got my copy of Watcom and could work in 32-bit mode, I gave up on near
and far and small and huge entirely. :)

== 10 of 11 ==
Date: Thurs, Feb 25 2010 8:04 pm
From: "Chris M. Thomasson"

"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:FQFhn.7944$jB5.2306@newsfe19.iad...
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:dqudnev74ty3gxrWnZ2dnUVZ8nGdnZ2d@bt.com...
>> Chris M. Thomasson wrote:
>> <snip>
>>
>>> Okay, but how would you implement my sample program using nothing but
>>> value-based containers?
>>
>> Step 1: using what we are now calling a "value-based" container, read in
>> the data, and pass a pointer to it, and its size, to the container add
>> function, e.g. array_add(&array, &foo, sizeof foo);
>>
>> Step 2 would go something like this:
>>
>> n = array_count(array);
>> for(i = 0; i < n; i++)
>> {
>> p = array_fetch(array, i);
>> list_add(&list, &p, sizeof p);
>> }
>
> Okay. I am curious as to how the list nodes internal structure would look?
> It seems like you could end up wasting some space in this case. For
> instance, if the node was like:
>
>
> struct node
> {
> struct node* next;
> void* data;
> size_t size;
> };
>
>
> Is the `node::size' member not wasted space if we only store a pointer to
> an object? Also, would the container have to actually allocate space for a
> pointer? Humm... Would the container have to make two allocations, 1 for
> the node, and 1 for the data in this case?

Well, according to your linked list implementation:

http://groups.google.com/group/comp.lang.c/browse_frm/thread/a77ea83913603f48

I would have to pay the penalty of allocating a node, and allocating space
for a pointer! IMVHO, this is completely unacceptable and it shows how a
value-based container is simply no good at all for certain problems.

== 11 of 11 ==
Date: Thurs, Feb 25 2010 11:00 pm
From: Richard Heathfield

Chris M. Thomasson wrote:

<snip>

> I would have to pay the penalty of allocating a node, and allocating
> space for a pointer! IMVHO, this is completely unacceptable

Fine, so don't use it.

> and it shows
> how a value-based container is simply no good at all for certain problems.

But for other problems, it's fine. There is no silver bullet.

--
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

==============================================================================
TOPIC: C99 is widely used!
http://groups.google.com/group/comp.lang.c/t/0ba05b02a32efc0a?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 25 2010 4:24 pm
From: Flash Gordon

Nick Keighley wrote:
> On 24 Feb, 22:29, Richard Heathfield <r...@see.sig.invalid> wrote:
>> jacob navia wrote:
>>> Seebs a �crit :
>
>>>> In embedded systems, it's quite common to stick with a stable, known,
>>>> version for 3-5 years, or even 10, because changes would require extremely
>>>> expensive revalidation.
>
> in the last year I've made a mod to a K&R program. I'd never actaully
> used K&R before. I think the chances of many thousands of lines of
> code being converted even to C89 is pretty slim!

It happens. I've converted program which was many thousands of lines of
C from K&R to C90, and I've probably got it up to C99 now (not making
use of it, but valid as C99). I even converted it to using prototypes
(not available in K&R) which made the compiler point out a number of
bugs which were in the code.
--
Flash Gordon

== 2 of 2 ==
Date: Thurs, Feb 25 2010 8:15 pm
From: cri@tiac.net (Richard Harter)

On Thu, 25 Feb 2010 01:42:45 -0800 (PST), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

>On 24 Feb, 22:29, Richard Heathfield <r...@see.sig.invalid> wrote:
>> jacob navia wrote:
>> > Seebs a =E9crit :
>
>> >> In embedded systems, it's quite common to stick with a stable, known,
>> >> version for 3-5 years, or even 10, because changes would require extre=
>mely
>> >> expensive revalidation.
>
>in the last year I've made a mod to a K&R program. I'd never actaully
>used K&R before. I think the chances of many thousands of lines of
>code being converted even to C89 is pretty slim!

You would have found writing portable code in the old days rather
enlightening. There were a multiplicity of implementations with
all sorts of variations. The libraries for SYS V Unix and BSD
Unix differed in their names and contents; specific vendors had
their own additional variants. UNIX was not the whole world;
there was VMS and PRIMOS. The early PRIMOS C was particularly
charming - it was a 32 bit segmented memory machine with 48 bit
char pointers. Other pointers were 32 bits. VMS was markedly
different from UNIX. The upshot was that maintaining a product
across a wide variety of platforms was, ah, exciting. What it
came down to was that programs running on multiple platforms
ended up with lots of platform dependent conditional code.

None-the-less one could write clean, portable C code.
(Cleanliness is always a matter of debate.)

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

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

== 1 of 6 ==
Date: Thurs, Feb 25 2010 6:56 pm
From: Kelsey Bjarnason

On Wed, 24 Feb 2010 22:09:43 +0000, Scott Lurndal wrote:

> James Harris <james.harris.1@googlemail.com> writes:
>>On 24 Feb, 20:53, BruceS <bruce...@hotmail.com> wrote:
>>
>>...
>>
>>> I would like to add that, as long as you're trying to use good style,
>>> for God's sake don't use the wrong indentation style. =A0If you put
>>> your opening braces on the same line as your conditional, you'll just
>>> look like a fool in front of your friends and colleagues.
>>
>>Snobbish nonsense!
>>
>>
>>
> Indeed.
>
> if (condition) {
>
> is preferred over
>
> if (condition)
> {

Not by me, it ain't. :)

> Makes it much more likely that a properly written function will fit on a
> single page/screen.

And less likely to catch proper vs improper bracing and indentation, when
the braces don't line up with the indents.

> In 30 years of C programming, no employer or project has used the latter
> form.

This is one of those cases where there really are legitimate reasons for
each approach, with the deciding factor being preference.

My take on this has always been to standardize the format "checked in",
then use indent or some equivalent, on check in and check out, to convert
between the "checkin format" and the individual coder's preferred format.

== 2 of 6 ==
Date: Thurs, Feb 25 2010 7:48 pm
From: Ben Pfaff

Kelsey Bjarnason <kbjarnason@gmail.com> writes:

> My take on this has always been to standardize the format "checked in",
> then use indent or some equivalent, on check in and check out, to convert
> between the "checkin format" and the individual coder's preferred format.

I've heard of this approach, but I always assumed that it was a
joke. You really use it?
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

== 3 of 6 ==
Date: Thurs, Feb 25 2010 9:05 pm
From: Phred Phungus

Keith Thompson wrote:
> John Bode <jfbode1029@gmail.com> writes:
> [...]
>> The all-caps convention makes it easier to distinguish preprocessor
>> macros from other symbols. This can matter, especially when using
>> function-like macros (macros that take arguments). Remember that
>> macro expansions are simple text substitutions; a macro like
>>
>> #define square(x) (x*x)
>>
>> does not compute "x*x" and return a value; it *replaces* the text
>> "square(x)" with "(x*x)". If x is "z++", then the replacement text is
>> "(z++*z++)", which invokes undefined behavior. If x is "a+b", then
>> the replacement text is "(a+b*a+b)". By using all-uppercase for
>> macros, it makes it easier to see potential red flags like "SQUARE(x+
>> +)" or "SQUARE(x+y)".
> [...]
>
> The side effect problem can't be solved (or at least can't be easily
> solved) if you're using a macro, but the operator precedence problem
> can.
>
> #define SQUARE(x) ((x)*(x))
>
> You need to parenthesize the entire definition *and* each reference to
> the parameter(s).
>
> BTW, here's my favorite example of preprocessor abuse:
>
> #include <stdio.h>
>
> #define SIX 1+5
> #define NINE 8+1
>
> int main(void)
> {
> printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
> return 0;
> }
>

$ gcc -D_GNU_SOURCE -Wall -Wextra k1.c -o out
$ ./out
6 * 9 = 42
$ cat k1.c
#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

// gcc -D_GNU_SOURCE -Wall -Wextra k1.c -o out
$

SIX * NINE equals 1 + 5 * 8 + 1

I save these nice little toy programs in my linuxlog.

--
fred

== 4 of 6 ==
Date: Thurs, Feb 25 2010 9:15 pm
From: Kelsey Bjarnason

On Thu, 25 Feb 2010 19:48:06 -0800, Ben Pfaff wrote:

> Kelsey Bjarnason <kbjarnason@gmail.com> writes:
>
>> My take on this has always been to standardize the format "checked in",
>> then use indent or some equivalent, on check in and check out, to
>> convert between the "checkin format" and the individual coder's
>> preferred format.
>
> I've heard of this approach, but I always assumed that it was a joke.
> You really use it?

I have, repeatedly, over the years.

The problem with _not_ doing it is that you tend to get a lot of checkins
where the "diff" is wildly out of sync with what actually got changed,
particularly if the coder's tools do things such as switching tabs to
spaces or re-organizing braces, etc, etc, etc, which many tools do.

By using indent or an equivalent on checkin, you ensure a standard format
going in, such that only "real" changes are recorded, and by using it on
checkout, you deliver to the coder whatever flavour he's happiest with.

Or, you can skip it on checkout and just let him use whatever tools he
likes, but I've found delivering to the developer something which he is
maximally comfortable with, right out of the gate, tends to produce
maximum productivity and minimum frustration.

'Course, some of that will depend on the repository tools, too. Some can
be set to ignore whitespace differences, or to auto-format to a defined
standard, etc, etc, etc. Some can't. It's easier just to do it
yourself, with indent or equivalent, as part of the check-in/check-out
procedure.

== 5 of 6 ==
Date: Thurs, Feb 25 2010 10:17 pm
From: "robertwessel2@yahoo.com"

On Feb 25, 11:15 pm, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> On Thu, 25 Feb 2010 19:48:06 -0800, Ben Pfaff wrote:
> > Kelsey Bjarnason <kbjarna...@gmail.com> writes:
>
> >> My take on this has always been to standardize the format "checked in",
> >> then use indent or some equivalent, on check in and check out, to
> >> convert between the "checkin format" and the individual coder's
> >> preferred format.
>
> > I've heard of this approach, but I always assumed that it was a joke.
> > You really use it?
>
> I have, repeatedly, over the years.
>
> The problem with _not_ doing it is that you tend to get a lot of checkins
> where the "diff" is wildly out of sync with what actually got changed,
> particularly if the coder's tools do things such as switching tabs to
> spaces or re-organizing braces, etc, etc, etc, which many tools do.
>
> By using indent or an equivalent on checkin, you ensure a standard format
> going in, such that only "real" changes are recorded, and by using it on
> checkout, you deliver to the coder whatever flavour he's happiest with.
>
> Or, you can skip it on checkout and just let him use whatever tools he
> likes, but I've found delivering to the developer something which he is
> maximally comfortable with, right out of the gate, tends to produce
> maximum productivity and minimum frustration.

A problem with that approach is that it will trash any special/careful
formatting that you might use to clarify a complex section of code.
While indent allows you to disable formatting for sections, that's not
an ideal solution in many ways.

On the flip side, some people can't be coerced into clean formatting,
or making an effort to follow the formatting already established for
the module their editing, no matter how much violence you threaten.
Or keeping "use tabs" turned off in their editors. At times that gets
bad enough that the easiest solution is to go ahead and run indent (or
the equivalent) and live with the damage.

But there's really no excuse - following a formatting style is not
that hard, even if it's not exactly the one you prefer. Frankly there
is almost no excuse for not follow the existing style when modifying a
program. Or following the shop standards when creating a new module.

== 6 of 6 ==
Date: Thurs, Feb 25 2010 10:58 pm
From: Richard Heathfield

Ben Pfaff wrote:
> Kelsey Bjarnason <kbjarnason@gmail.com> writes:
>
>> My take on this has always been to standardize the format "checked in",
>> then use indent or some equivalent, on check in and check out, to convert
>> between the "checkin format" and the individual coder's preferred format.
>
> I've heard of this approach, but I always assumed that it was a
> joke.

Really? Why so?

> You really use it?

I can't speak for Kelsey, obviously, but I wouldn't dream of doubting
him. And I've used it in a couple of places. It works very well.

--
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

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

== 1 of 1 ==
Date: Thurs, Feb 25 2010 7:28 pm
From: spinoza1111

On Feb 26, 3:39 am, Tim Streater <timstrea...@waitrose.com> wrote:
> On 25/02/2010 19:23,spinoza1111wrote:
>
> > On Feb 25, 5:29 pm, blm...@myrealbox.com<blm...@myrealbox.com> wrote:
> >> In article<bdac8263-e941-4955-9875-44d4ff741...@k18g2000prf.googlegroups.com>,
>
> [snip]
>
> >> There's a semi-sane answer here in the last case, but isn't
>
> > HOW.DARE.YOU. How DARE you start talking about sanity? It isn't
> > collegial, and it is libel and completely insensitive. It's talking
> > like those thugs and shitheads here, Seebach and Heathfield.
>
> Hmmm, I was wondering how long it would take. You oil up to women
> posters here until they find you out and then you lose it with them too.
> It becomes clearer and clearer how Richard Heathfield's list so aptly
> describes you.

No, I treat all posters, male or female, with decency and respect
until they foolishly or ignorantly or thoughtlessly use their relative
anonymity to start introducing off-topic personal abuse.

You see, it's been impossible for anyone to narrate this type of
relation, since the 1960s, as anything but the weakness they feel in
themselves.

I don't give a flying fuck about blm's gender, and I ain't lookin' for
a date. Are you? Had she been a male, acting with relative restraint
and collegiality as she has, I would have said the same thing. Had
this male then started in, calling good questions "insane" (as John
Conway treated Nash) I would have responded in exactly the same way.

Men have learned self-protectively to narrate lives without honor, but
I missed the class.
>
> I hope you also realise that by screaming that you want Mr Heathfield
> "out of this ng", IOW by appointing yourself as clc monitor, you become
> the chief "reg", and your brown-nosers "Richard", "Kenny", and Twinky
> become your co-conspirators.

Gee, I have fans? I wasn't aware of that. I don't think Richard, Kenny
or da Twink count. I think they are instead independent spirits who
think for themselves.
>
> --
> Tim
>
> "That the freedom of speech and debates or proceedings in Parliament
> ought not to be impeached or questioned in any court or place out of
> Parliament"
>
> Bill of Rights 1689

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

== 1 of 3 ==
Date: Thurs, Feb 25 2010 8:16 pm
From: Phred Phungus

I've been reading up on the whole Plan 9 thing. Links here:

Brian Kernigan's treatment:

http://doc.cat-v.org/plan_9/2nd_edition/README

The wiki:

http://en.wikipedia.org/wiki/Plan_9

They always talk about portability, but if you have to drag the Plan 9
OS around in order to use Pcc, well that's almost the precise opposite.
I looked at the package manager for ubuntu to see if a Pcc were
available, but got nothing.

My question is whether I can get Pcc without having to create a Plan 9
partition.

Thanks for your comment and cheers,
--
fred

== 2 of 3 ==
Date: Thurs, Feb 25 2010 10:01 pm
From: William Ahern

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.

== 3 of 3 ==
Date: Thurs, Feb 25 2010 10:18 pm
From: Abubacker

On Feb 26, 9:16 am, Phred Phungus <Ph...@example.invalid> wrote:
> I've been reading up on the whole Plan 9 thing. Links here:
>
> Brian Kernigan's treatment:
>
> http://doc.cat-v.org/plan_9/2nd_edition/README
>
> The wiki:
>
> http://en.wikipedia.org/wiki/Plan_9
>
> They always talk about portability, but if you have to drag the Plan 9
> OS around in order to use Pcc, well that's almost the precise opposite.
> I looked at the package manager for ubuntu to see if a Pcc were
> available, but got nothing.
>
> My question is whether I can get Pcc without having to create a Plan 9
> partition.
>
> Thanks for your comment and cheers,
> --
> fred

Dear friend ,
Pcc acts as a front-end to the Plan9 loaders and compilers ,but it is
a combination of
ANSI as well as POSIX standards , I also looked its directives style
that doesn't look weird.
not sure that whether it may run in windows , but I hope that it would
run in all the unix distribution, currently it is not available it may
be gettable in the future.

==============================================================================
TOPIC: tcp server: how to send message to all the connected client at every
time interval
http://groups.google.com/group/comp.lang.c/t/a222c6094f2760ff?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 25 2010 10:25 pm
From: Abubacker

On Feb 25, 11:48 am, "ganesh.kunda...@gmail.com"
<ganesh.kunda...@gmail.com> wrote:
> Hi,
> I want to come up with a server which will send some message like
> "goodbye" or something else to all the connected client at every 10
> sec interval. Could somebody plz help me how to send message to all
> the connected client at every 10 sec interval.
>
> Thanks,
> Ganesh

Need to make some changes after implementing a single client and
server connection establishment
, after that use select function and maintain a fd set of all the
connected client ,
I hope that if you are thorough in the select function then it'll
solve all your requirement,

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

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

Thursday, February 25, 2010

comp.lang.c - 24 new messages in 6 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts