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

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: initialize for a 2-D dynamic array.
http://groups.google.com/group/comp.lang.c/t/10b972fd49323b34?hl=en
==============================================================================

== 1 of 9 ==
Date: Sun, Feb 28 2010 8:29 am
From: Malcolm McLean

On Feb 28, 5:46 pm, la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>
> This can be generalized for N dimensional arrays. The following function
> takes "long unsigned" arguments instead of "size_t", because "size_t"
> may be promoted by the default argument promotions, and that doesn't
> play very well with va_arg().
>
Ho ho, hadn't thought of that. Neither, I bet, had the committee.
size_t introduces all sorts of subtle difficulties.

== 2 of 9 ==
Date: Sun, Feb 28 2010 9:09 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <8c2ee3da-7c0a-4a59-8947-e0d3d31d7821@19g2000yqu.googlegroups.com>, Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Feb 28, 5:46=A0pm, la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>>
>> This can be generalized for N dimensional arrays. The following function
>> takes "long unsigned" arguments instead of "size_t", because "size_t"
>> may be promoted by the default argument promotions, and that doesn't
>> play very well with va_arg().
>>
> Ho ho, hadn't thought of that. Neither, I bet, had the committee.

I'm sure they did; after all, C99 has %z. Since any specific
implementation of the standard library knows intimately what size_t is
promoted to (if at all), they can use the promoted type in va_arg() in
the implementation of *printf().

Granted, if one wishes to take size_t's through the ellipsis in a
portable function, he/she has to transfer "long unsigned"'s instead --
in C90.

In C99, the previous paragraph works with s/long unsigned/uintmax_t/g,
but I think there is also a chance to figure out the type size_t is
promoted to -- C99 has SIZE_MAX.

(I wouldn't try it, though, with padding bits and whatnot :))

Cheers,
lacos

== 3 of 9 ==
Date: Sun, Feb 28 2010 9:34 am
From: Ben Bacarisse

lacos@ludens.elte.hu (Ersek, Laszlo) writes:
<snip>
> This can be generalized for N dimensional arrays. The following function
> takes "long unsigned" arguments instead of "size_t", because "size_t"
> may be promoted by the default argument promotions, and that doesn't
> play very well with va_arg().

That's a bit vague. What is the problem with size_t that unsigned
long solves?

<snip>
--
Ben.

== 4 of 9 ==
Date: Sun, Feb 28 2010 9:29 am
From: Seebs

On 2010-02-28, Ike Naar <ike@localhost.claranet.nl> wrote:
> In article <slrnhok9jn.mqh.usenet-nospam@guild.seebs.net>,
> Seebs <usenet-nospam@seebs.net> wrote:
>>On 2010-02-28, MBALOVER <mbalover9@gmail.com> wrote:
>>> I did a search and found:
>>> 1. array = (** unsigned char) calloc(NROW, sizeof(unsigned char*));

>>This is clearly incorrect.

> Why? It looks like mbalover is constructing a "dynamic 2D array"
> as an array of pointers, pointing to 1D arrays. What's incorrect
> about that? It's a well-known idiom.

"(** unsigned char)".

I'm pretty sure the * would have to go after the base type.

> You mean, like "char array[NROW][NCOL]"? That's indeed a possibility,
> but apparently not what mbalover wants (perhaps he wants to be able to
> later resize his "dynamic 2D array", something he can't do with a
> regular 2D array).

Probably. But if he knows what NCOL is at compile time, he can allocate space
for an array of arrays of size NCOL, and that'll work.

> Agreed; the speed difference between calloc and malloc (if there is one,
> and if it is measurable) is probably the last thing to worry about.

It's also extremely hard to predict. I'm aware of a particular test case
where calloc() appeared to be much faster than using malloc() and then
initializing memory... But only if you allocated a large space and then
didn't touch most of it. If the space was smaller, or if you touched most
of it, calloc() was much slower.

(I'm not going to explain why right away, because I bet there's people who
would love a chance to kick that one around a bit.)

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

== 5 of 9 ==
Date: Sun, Feb 28 2010 10:32 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article
<0.a9879b0ea15bbfd5e53e.20100228173454GMT.87iq9hfem9.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> lacos@ludens.elte.hu (Ersek, Laszlo) writes:

>> This can be generalized for N dimensional arrays. The following function
>> takes "long unsigned" arguments instead of "size_t", because "size_t"
>> may be promoted by the default argument promotions, and that doesn't
>> play very well with va_arg().
>
> That's a bit vague. What is the problem with size_t that unsigned
> long solves?

(I chose long unsigned instead of uintmax_t for C90's sake, but that's
not significant now.)

C90 7.8.1.2 The va-arg macro

----v----
Synopsys

#include <stdarg.h>

type va_arg(va_list ap, type);

Description

The *va_arg* macro expands to an expression that has the type and value
of the next argument in the call. The parameter *ap* shall be the same
as the *va_list ap* initialized by *va_start*. Each invocation of
*va_arg* modifies *ap* so that the values of successive arguments are
returned in turn. The parameter /type/ is a type name specified such
that the type of a pointer to an object that has the specified type can
be obtained simply by postfixing a * to /type/. If there is no actual
next argument, or if /type/ is not compatible with the type of the
actual next argument (as promoted according to the default argument
promotions), the behavior is undefined.

[...]
----^----

C90 7.1.6 Common definitions <stddef.h>

----v----
[...]

size_t

which is the unsigned integral type of the result of the *sizeof*
operator

[...]
----^----

C90 6.3.3.4 The sizeof operator

----v----
[...]

The result is an integer constant.

[...]
----^----

In my interpretation all these permit size_t to be "short unsigned".
"short unsigned" is promoted to "int" or "unsigned" by the integral
promotions as part of the default argument promotions ("integral" is the
word in C90). Hence,

- size_t may be "short unsigned",
- it is then promoted to "int" or "unsigned",
- making size_t and its promoted type incompatible,
- which makes va_arg(ap, size_t) undefined behavior.

Choosing "long unsigned" (or uintmax_t under C99) solves this: they are
unaffected by integral (integer) promotions, and they can hold any
size_t value (no matter what size_t is).

(In my interpretation, C90 7.8.1.2 wishes to allow the implementation to
include a dereference like

*(type *)ap

in the implementation of va_arg(). Now if size_t is "short unsigned",
and therefore it is promoted to "int" (or "unsigned"), and if "short
unsigned" and its promoted type actually have different representations
(eg. by having different sizes), then the access above may translate to
something like

{
uint32_t u;

*(uint16_t *)&u;
}

which is kind of lossy, especially on big-endian.)

Cheers,
lacos

== 6 of 9 ==
Date: Sun, Feb 28 2010 10:37 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <tt07qBwxN6rY@ludens>, lacos@ludens.elte.hu (Ersek, Laszlo) writes:

> C90 6.3.3.4 The sizeof operator
>
> ----v----
> [...]
>
> The result is an integer constant.
>
> [...]
> ----^----
>
> In my interpretation all these permit size_t to be "short unsigned".

Oh no! After looking up C90 6.1.3.2 "Integer constants", I realize
nothing with a lower conversion rank than that of "int" can be size_t.
And thus size_t is not affected by the integer promotions.

Sorry :)

lacos
/facepalm

== 7 of 9 ==
Date: Sun, Feb 28 2010 11:12 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <slrnholabf.mm3.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> writes:

> I'm aware of a particular test case
> where calloc() appeared to be much faster than using malloc() and then
> initializing memory... But only if you allocated a large space and then
> didn't touch most of it. If the space was smaller, or if you touched most
> of it, calloc() was much slower.
>
> (I'm not going to explain why right away, because I bet there's people who
> would love a chance to kick that one around a bit.)

You are a skilled manipulator (and I'm easy game).

If calloc() sees that the size of the region to allocate exceeds (or
reaches?) the mmap threshold of the malloc() implementation, then it
mmap()'s a new VMA instead of picking an already mapped (and previously
used) part of the heap VMA. (Or it extends the heap VMA with new pages
by way of sbrk() or whatever.) The kernel must ensure (for, among other
reasons, security) that when read, all such pages act as if they had
been initialized with 0. calloc() knows this and can omit the explicit
stores, which saves CPU cycles and page faults (and even initial page
assignments to the VMA or so).

I hope this is inaccurate / wrong enough that others still feel like
kicking it around (supposing I'm the first biting the bait, which is
unlikely).

Cheers,
lacos

== 8 of 9 ==
Date: Sun, Feb 28 2010 12:15 pm
From: Keith Thompson

lacos@ludens.elte.hu (Ersek, Laszlo) writes:
> In article <tt07qBwxN6rY@ludens>, lacos@ludens.elte.hu (Ersek, Laszlo) writes:
>> C90 6.3.3.4 The sizeof operator
>>
>> ----v----
>> [...]
>>
>> The result is an integer constant.
>>
>> [...]
>> ----^----
>>
>> In my interpretation all these permit size_t to be "short unsigned".
>
> Oh no! After looking up C90 6.1.3.2 "Integer constants", I realize
> nothing with a lower conversion rank than that of "int" can be size_t.
> And thus size_t is not affected by the integer promotions.
>
> Sorry :)

I think you've been led astray by some incorrect wording.

C99 6.5.3.4p2 has the same problem; it says:

If the type of the operand is a variable length array type, the
operand is evaluated; otherwise, the operand is not evaluated
and the result is an integer constant.

But the phrase "integer constant" cannot refer to the
syntactic category "integer-constant" defined in C99 6.4.4.1.
An "integer-constant" is a decimal, octal, or hexadecimal constant,
optionally followed by a suffix such as "UL"; it's a single token.
Even "-1" isn't an integer constant; it's a "-" token followed by
an integer constant. Clearly anything that includes the "sizeof"
keyword cannot be an "integer-constant".

What it probably should say is that "sizeof ..." is an "integer
constant expression" as defined in C99 6.6p6. The point is that the
result is constant (evaluated at compile time). The tricky part
is saying that without misusing the word "constant" as defined in
C99 6.4.4.

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

== 9 of 9 ==
Date: Sun, Feb 28 2010 1:45 pm
From: ike@localhost.claranet.nl (Ike Naar)

In article <0.85452ca540774a94536d.20100228140231GMT.87zl2tfog8.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>It has a syntax error. (** unsigned char) is not a valid cast operator.

Oops of course. The error is so obvious that I missed it.

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

== 1 of 3 ==
Date: Sun, Feb 28 2010 8:47 am
From: nobody@xmission.com (Scott)

On Sun, 28 Feb 2010 10:08:27 +0000 (UTC), in comp.lang.c, Willem
<willem@snail.stack.nl> wrote:

>Scott wrote:
>) On Sat, 27 Feb 2010 22:39:26 +0000 (UTC), in comp.lang.c, Willem
>)<willem@snail.stack.nl> wrote:
>)>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.
>
>Perhaps you should switch to Perl.

Eh. No. Just...no.

>In C, the result of any boolean operator is always 0 or 1.
>Dunno why, perhaps because existing compilers did it that way and
>code existed that used the result of the boolean for arithmetics.

Yes, yet writing C according to my stated assumption above still yeilds
semantically correct code. And it keeps me in the right frame of mind,
without having to stop to think about it, to handle languages where
"true==1" isn't necessarily so, ultimately producing fewer bugs.

== 2 of 3 ==
Date: Sun, Feb 28 2010 9:33 am
From: Seebs

On 2010-02-28, Willem <willem@snail.stack.nl> wrote:
> Perhaps you should switch to Perl. There, (a||b) is defined as (a?a:b)
> (But, obviously, with a only being evaluated once).
> And, incidentally, (a&&b) is defined as (a?b:a).

Ruby is the same way, at least with ||.

> In C, the result of any boolean operator is always 0 or 1.

PHP is the same way, at least with ||.

... Note that if you happen to be doing two projects, both web based, one in
Ruby and one in PHP, this is a particularly irritating difference.

Although it's an extension, GNU C has a very nice way to express that:
a ?: b

I actually sorta wish that ISO C would pick that one up, it's very expressive.

== 3 of 3 ==
Date: Sun, Feb 28 2010 10:01 am
From: Willem

Scott wrote:
) On Sun, 28 Feb 2010 10:08:27 +0000 (UTC), in comp.lang.c, Willem
)<willem@snail.stack.nl> wrote:
)
)>Scott wrote:
)>) On Sat, 27 Feb 2010 22:39:26 +0000 (UTC), in comp.lang.c, Willem
)>)<willem@snail.stack.nl> wrote:
)>)>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.
)>
)>Perhaps you should switch to Perl.
)
) Eh. No. Just...no.
)
)>In C, the result of any boolean operator is always 0 or 1.
)>Dunno why, perhaps because existing compilers did it that way and
)>code existed that used the result of the boolean for arithmetics.
)
) Yes, yet writing C according to my stated assumption above still yeilds
) semantically correct code. And it keeps me in the right frame of mind,
) without having to stop to think about it, to handle languages where
) "true==1" isn't necessarily so, ultimately producing fewer bugs.

I was under the mistaken impression that I was talking to the same person
who was amazed that (7||8) yielded 1. You know, the one that my question
was directed to. Of course, I should have checked the name. My apology.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

== 1 of 2 ==
Date: Sun, Feb 28 2010 9:34 am
From: "Bill Cunningham"

"osmium" <r124c4u102@comcast.net> wrote in message
news:7uu1u6Fja6U1@mid.individual.net...

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

Ok then google was the problem then. I think I'm going to look for a
windows version of a unix news client.

Bill

== 2 of 2 ==
Date: Sun, Feb 28 2010 10:45 am
From: Keith Thompson

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "osmium" <r124c4u102@comcast.net> wrote in message
> news:7uu1u6Fja6U1@mid.individual.net...
>
>> 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.
>
> Ok then google was the problem then. I think I'm going to look for a
> windows version of a unix news client.

Perhaps you could consider going back to using Thunderbird, as you did
for two articles you posted here on January 8. Here's one of them:

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

== 1 of 3 ==
Date: Sun, Feb 28 2010 9:37 am
From: Seebs

On 2010-02-28, Dan C <youmustbejoking@lan.invalid> wrote:
> Really? He couldn't click the friggin link he claimed was the correct
> website, and see immediately that it is not a functioning website?

Why should he have clicked a link that he'd been to hundreds of times?

> Get a clue.

I like the way that, on every single occasion when any suggestion has
been made that your behavior might be rude, you've completely ignored it
in favor of attempts to insult or deride people, usually based on completely
unrelated trivia, like what host their newsreader is running on.

... Well, "like" is maybe a bit strong a term. To be more specific, as long
as you appear to have no goals that in any way involve advancing or furthering
human society, but wish only to denigrate other people to try to preserve
for yourself some illusion of relative worth, I'm glad that you're so
stunningly obvious and incompetent about it that virtually no one will ever
take anything you say seriously.

And again, please stop using or advocating Linux, free software, or anything
else. "Advocates" like you are one of the major barriers to broader
acceptance of free software, because very few sane people would willingly be
thought to be in some way associated with or similar to someone who behaves
the way you do. I would recommend as an alternative that you pursue a few
years of serious therapy to see if you can develop a way of feeling good
about yourself other than laughably inept put-downs of other people. (And if
you can't, please take a page from someone like spinoza1111, and be funnier
about it.)

== 2 of 3 ==
Date: Sun, Feb 28 2010 11:25 am
From: Phred Phungus

Vivien MOREAU wrote:
> ["Followup-To:" header set to comp.lang.c.]
> On 2010-02-26, Phred Phungus wrote:
>
>> My question is whether I can get Pcc without having to create a Plan 9
>> partition.
>
> The answer is yes. Read <http://swtch.com/9vx/> ;-)
>

Thx, Vivian.

$ ls -l
total 8028
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:43 386
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:43 68000
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:43 68020
-rwxr-xr-x 1 dan dan 2607800 2008-07-01 08:30 9vx.FreeBSD
-rwxr-xr-x 1 dan dan 2626815 2008-07-01 08:30 9vx.Linux
-rwxr-xr-x 1 dan dan 2803052 2008-07-01 08:30 9vx.OSX
drwxrwxr-x 7 dan dan 4096 2008-06-30 07:43 acme
drwxrwxr-x 3 dan dan 4096 2008-06-30 07:44 adm
drwxrwxr-x 6 dan dan 4096 2008-06-30 07:43 alpha
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:43 amd64
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:43 arm
drwxrwxr-x 3 dan dan 4096 2008-06-30 07:43 cfg
drwxrwxr-x 4 dan dan 4096 2008-06-30 07:43 cron
drwxrwxr-x 3 dan dan 4096 2008-06-30 07:43 dist
drwxrwxr-x 2 dan dan 4096 2008-06-30 07:40 env
drwxrwxr-x 2 dan dan 4096 2008-06-30 07:40 fd
drwxrwxr-x 12 dan dan 4096 2008-06-30 07:43 lib
-r--r--r-- 1 dan dan 13006 2008-06-30 07:41 LICENSE
-rw-rw-r-- 1 dan dan 14333 2008-06-30 07:40 LICENSE.afpl
-rw-rw-r-- 1 dan dan 15081 2008-06-30 07:40 LICENSE.gpl
drwxrwxr-x 6 dan dan 4096 2008-06-30 07:42 lp
drwxrwxr-x 10 dan dan 4096 2008-06-30 07:42 mail
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:42 mips
drwxrwxr-x 26 dan dan 4096 2008-06-30 07:42 mnt
drwxrwxr-x 25 dan dan 4096 2008-06-30 07:42 n
-r--r--r-- 1 dan dan 63 2008-06-30 07:40 NOTICE
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:42 power
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:42 power64
drwxrwxr-x 4 dan dan 4096 2008-06-30 07:42 rc
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:42 sparc
drwxrwxr-x 5 dan dan 4096 2008-06-30 07:42 sparc64
drwxrwxr-x 9 dan dan 4096 2008-06-30 07:42 sys
dr-xr-xr-x 2 dan dan 4096 2008-06-30 07:40 tmp
drwxrwxr-x 3 dan dan 4096 2008-06-30 07:42 usr
$ grep -rl Pcc
^C
$

I think this is telling me that there are 8 thousand files. Where is
Pcc, and what was the correct way to look for it with grep?
--
fred

== 3 of 3 ==
Date: Sun, Feb 28 2010 1:46 pm
From: Vivien MOREAU

On 2010-02-28, Phred Phungus wrote:

> Thx, Vivian.

Vivien. ;-)

> [...]
>
> I think this is telling me that there are 8 thousand files. Where is
> Pcc, and what was the correct way to look for it with grep?

The source code is in sys/src/cmd/pcc/ . You could search for
it with find or du and grep, for example.

You should also look at some papers, especially "The
ANSI/POSIX Environment".

<http://plan9.bell-labs.com/sys/doc/>
<http://plan9.bell-labs.com/sys/doc/ape.html>

(sorry for my english...)
--
Vivien MOREAU / vpm

« Unix is simple. It just takes a genius to understand its simplicity »
Dennis M. Ritchie

==============================================================================
TOPIC: fputs and fprintf
http://groups.google.com/group/comp.lang.c/t/d665d0bf528f7433?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 9:51 am
From: Richard Heathfield

Stefan Ram wrote:
> _JusSx_ <jussx0NOSPAM@gmail.com.invalid> writes:
>> I would like to know what differences are between these two
>> C functions: *fputs* and *fprintf*.
>
> Remarkable: The answer I would expect to be most often
> did not occur at all so far (in the subset of the posters
> I read):
>
> fprintf( stderr, userinput );

That would be very, very silly - a bit like crossing the road with your
eyes shut.

> An attacker who can fully or partially control the contents
> of a format string can crash a vulnerable process, view the
> contents of the stack, view memory content, or write to an
> arbitrary memory location and consequently execute arbitrary
> code with the permissions of the vulnerable process [Seacord 05a].

Which is the reason you don't give attackers control of the format string.

>
> [Seacord 05a] Seacord, Robert C. Secure Coding in C and C++.
> Boston, MA: Addison-Wesley, 2005. See
> http://www.cert.org/books/secure-coding for news and errata.

Yeah. I started reviewing his stuff in considerable detail, but he
seemed to lose interest after the Nth crit (for large N).

--
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: 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: Sun, Feb 28 2010 10:00 am
From: _JusSx_

On 2010-02-25, Ian Collins <ian-news@hotmail.com> wrote:
> Nick Keighley wrote:
>> On 25 Feb, 06:48, "ganesh.kunda...@gmail.com"
>> <ganesh.kunda...@gmail.com> wrote:
>>
>>> 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.
>>
>> you probably want to ask this on a platform specific group. A Unix
>> group is probably ok for general socket stuff.
>
> The OP already has.
>

Hi,
I'm too lazy to explain here and now how to do what you asked. So I
suggest to read this http://beej.us/guide/bgnet/. I have learned a lot
about socket programming.

-JusSx-

--
Linux is only free if your time has no value

==============================================================================
TOPIC: books by clc contributors
http://groups.google.com/group/comp.lang.c/t/fc106b79706dfb78?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Feb 28 2010 10:27 am
From: Phred Phungus

Ben Pfaff wrote:
> BruceS <bruces42@hotmail.com> writes:
>
>> If you've written a technical book, how was the experience for
>> you? How well did it sell, and how has that affected your
>> experience of writing? Would you do it again?

I have the unequal experience of reading about clc in _Unleashed_ and
finding the authors here. Lawrence Kirby and Jack Klein were hanging
around back then. So Dann Corbit became the sort guy, because that was
his chapter.

Heathfield described clc as a "rough and tumble place." I was hooked.
>
> I contributed a chapter to _C Unleashed_. It took more time than
> it was worth: I only made about $1000 (before taxes) and spent, I
> imagine, hundreds of hours on it. The reviewing was very poor
> also (although I hear that other contributors had better
> editors).

Your chapter is eminently readable. I think it's gotta be tough to find
editors who know the jargon and want to work for the type of peanuts you
were making.
>
> In the future, I am more likely to release my writings for free
> on the Internet than to write them for a publisher, at least if
> the publisher gets all the rights. I hear a lot more about GNU
> libavl (which is sort of an online book of mine) than I ever do
> about C Unleashed.

I don't mean to compound your frustration here, but is this library from
the avl that came on the source disc?

What rights do you mean here? Isn't it somwewhat contrary to the gnu
license to restrict distribution?
--
fred

== 2 of 3 ==
Date: Sun, Feb 28 2010 1:25 pm
From: Ben Pfaff

Phred Phungus <Phred@example.invalid> writes:

> Ben Pfaff wrote:
>> In the future, I am more likely to release my writings for free
>> on the Internet than to write them for a publisher, at least if
>> the publisher gets all the rights. I hear a lot more about GNU
>> libavl (which is sort of an online book of mine) than I ever do
>> about C Unleashed.
>
> I don't mean to compound your frustration here, but is this library
> from the avl that came on the source disc?

No, it is at http://adtinfo.org.

> What rights do you mean here? Isn't it somwewhat contrary to the gnu
> license to restrict distribution?

I mean, I signed over the copyright and other rights to the text
of that chapter to the publisher.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

== 3 of 3 ==
Date: Sun, Feb 28 2010 1:31 pm
From: jacob navia

BruceS a écrit :
> I've seen a number of critiques by some posters of books written by
> others (contributors or not), and this has probably been done to
> death. I'm interested in the other side of it. I've helped edit a
> technical book, and that was enough to make the *writing* of one look
> downright painful. People have told me I should write a book, but so
> far I've always veered away. If you've written a technical book, how
> was the experience for you?

It is a lot of work

How well did it sell, and how has that
> affected your experience of writing?

This book has helped my compiler system to be a long time
hit in the downloaded copies side: the book provides a lot of
documentation about C, windows, and some other subjects. It has
helped make lcc-win popular

Would you do it again?

Yes

Is it
> something (like teaching) that you really only do for the joy of it,
> or does it pay decently?

lcc-win has payed OK. The book is distributed at no charge, like
the software

How did you choose the specific subject area
> you wrote about?
>

I wanted to document the user side of my software.
I wrte another, explaining the technical side but it wasn't as populaer
and I did not go on with it.

You can download it with the software at

http://www.q-software-solutions.de

jacob

==============================================================================
TOPIC: More quirks importing from bsd
http://groups.google.com/group/comp.lang.c/t/3879f22a8a1b80ee?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Feb 28 2010 11:14 am
From: William Ahern

In comp.lang.c Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
> In comp.unix.programmer santosh <santosh.k83@gmail.com> wrote:
> > Since the source is available, and it's easy to implement your own as
> > well, with the same semantics, it's not a big portability problem,
> > AFAICS.

> Yeah. I am just deciding how to do that now. I have stumbled across a library
> called libnostd that contains an implementation of this. I could use that
> library. I am a bit concerned about the transparency issue of that though,
> because it still uses string.h and this means that code using string.h
> but using strlcat will work directly on some systems, but not on other
> systems where strlcat is not implement (so much for standard C libraries huh!).

I think you're a bit confused about what libnostd* does.

libnostd provides static inline versions of strlcpy, strlcat, and many other
routines. By adding "[path to libnostd]/bsd", a supported compiler (gcc,
msc, several others) will pick up the included "string.h" automatically.

bsd/string.h will include the system's string.h. Then bsd/string.h will
define routines such as strlcat() if it doesn't believe that they're already
declared (and thus available in libc).

Everything is defined static inline**, so there's no linking dependency
whatsoever. Once your code is compiled, that's the end of it.

libnostd is intended to be totally transparent. By simply adding bsd/ to
your include path, you should be able to safely use strlcat() everywhere w/o
worrying about it, and w/o having to modify any of the application code.

The way I use libnostd is to simply include it at the top-level of my
projects as a compat/ directory.

foo/
compat/
src/

The Makefile in src/ simply does

CPPFLAGS=-I../compat -I../compat/bsd

That's the end of it. In your source you include <string.h> confident that
strlcat() will be provided one way or another. Similarly, if you
`-I../compat/gnu' you can be confident that strnlen() is available.

<snip>
> does not create a conflicting definition. Also, what do I do about alternative
> implementations of strlcat, which zero the last byte of the buffer? Do I just
> drop support for those platforms, or do I create a new function name with
> equal functionality to avoid ambiguity? What a mess!

You can do what libnostd does: declare/define your version as xstrlcpy(),
and then `#define strlcpy(a, b, c) xstrlcpy((a), (b), (c))'.

* I'm the author of libnostd. It's not a particularly ambitious library.
I've never tested it on HP-UX or AIX. It works on the platforms I work with:
Linux, OS X, OpenBSD, Win32. I occassionally get patches for FreeBSD. But
the strlcpy() and strlcat() support should be near universal (assuming the
compiler supports interposing string.h), because even if it guesses wrong it
simply diverts usage to the inline definition; no harm no foul.

** Everything is static inline (including arc4random), except for
the recent setproctitle implementation. libnostd doesn't install anything,
and there's no independent build step. It's just meant to take the hassle
out of these minor portability issues.

== 2 of 2 ==
Date: Sun, Feb 28 2010 11:22 am
From: William Ahern

In comp.lang.c Mark Hobley <markhobley@hotpop.donottypethisbit.com> wrote:
> 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

If you're only porting to Linux you can either use the getprogname()
implemented in libnostd, or just read over the code in
bsd/stdlib/getprogname.h.

For Linux (or rather glibc and compatible libraries) the simple substitute
is `extern char *program_invocation_short_name'.

==============================================================================
TOPIC: Earn Money Online without Investment
http://groups.google.com/group/comp.lang.c/t/d797977aaf9f1e1a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 1:47 pm
From: "ranga..............."

Earn Money Online without Investment

Now anyone can earn money online with out any investment by using some
genuine websites.
The detailed information of some of the genuine everseen good earnings
website information are presented clealy for free at

http://earnmoneyonline-without-investment.blogspot.com/2010/02/earn-money-with-e-mail-marketing-how-it.html

Earn Money Online with out Inevstment Overview :

Earn Money By :

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

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

Sunday, February 28, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts