twitter: comp.lang.c - 26 new messages in 7 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* Letter sent to Apress with concerns about Peter Seebach's online behavior -
2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
* Please welcome me to the groupï Š - 7 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/4cfa313d9ef6fc05?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 11
messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* two C "style" questions - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/f72ed27fa289d30e?hl=en
* Does GCC optimize variadic functions to death? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/00b2bccdde28fde4?hl=en
* Efficency and the standard library - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* Is allocating large objects on the stack a good practice? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/ce22843b03b7665b?hl=en

==============================================================================
TOPIC: Letter sent to Apress with concerns about Peter Seebach's online
behavior
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 16 2010 12:58 pm
From: "Morris Keesan"

On Tue, 16 Mar 2010 14:13:30 -0400, John Bode <jfbode1029@gmail.com> wrote:

> I remember the bad old days before C89, but the kinds of errors
> Schildt made weren't due to the fact that implementations varied.
> Code like
>
> Page 53:
> /* Write 6 integers to a disk file. */
> void put_rec(int rec[6], FILE *fp)
> {
> int len;
>
> len = fwrite(rec, sizeof rec, 1, fp);
> if (len != 1) printf("write error");
> }
>
> wasn't going to work correctly *anywhere*.

It works fine on my DeathStation 9000,
on days when sizeof(int *) == 6 * sizeof(int).

--
Morris Keesan -- mkeesan@post.harvard.edu

== 2 of 2 ==
Date: Tues, Mar 16 2010 2:28 pm
From: John Bode

On Mar 16, 1:32 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-03-16, John Bode <jfbode1...@gmail.com> wrote:
>
> > So now who's engaging in defamation?
>
> Ahh, yeah. That seems to be the thing everyone runs into.
>
> Interestingly, I've pointed out a few times that I am, in fact,
> a professional programmer, and that a big hunk of what I do is write
> code (although not all of it is in C -- I do a lot of shell, and a fair
> bit of Very Dark Magic in GNU make).

You know, I knew that, but was tacitly awarding the point to Nilges in
my response. Bad me, no cookie. I should have known better, and
apologize for being a dipshit.

> So at this point, it's not just
> that Nilges is continuing to make false and defamatory statements about
> me, but that he's doing so despite correction.
>

But that's *different*, you see. Nilges isn't committing the
unpardonable sin of pointing out where you made mistakes in a
published work. He's just accusing you of launching a smear campaign
to make your bones with the developer community, which is nothing,
really.

It's like lying under oath about having an affair vs. lying under oath
about outing a covert intelligence agent. The former is a gross
affront to the rule of law and an impeachable offense, but the latter
isn't even worth a slap on the wrist, much less jail time.

What, me, bitter? Perish the thought.

> But fundamentally, as long as he's a sufficiently blatant kook that no
> one will ever take those criticisms seriously, I don't see any reason to
> care. It's actually sort of funny. I am beginning to regret having
> plonked him, if only because I could use his quotes in my next performance
> review. :)
>

Sort of a like a Bill "Wrong Way" Kristol for programmers, huh?

==============================================================================
TOPIC: Please welcome me to the groupï Š
http://groups.google.com/group/comp.lang.c/t/4cfa313d9ef6fc05?hl=en
==============================================================================

== 1 of 7 ==
Date: Tues, Mar 16 2010 1:01 pm
From: Andrew Poelstra

On 2010-03-16, heartsee1 <carolinabasaloalcid@gmail.com> wrote:
> Been using google since it's started but I just heard google groups
> yesterday
> guys give you right to laugh… weird hah?
>
> I'm just so excited to explore this social network some more…
>

This is not a social network. It is a technical discussion
group on Usenet. Please use only sentences containing both
a subject and predicate, or C code.

> Carolina

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

== 2 of 7 ==
Date: Tues, Mar 16 2010 1:12 pm
From: Keith Thompson

Andrew Poelstra <apoelstra@localhost.localdomain> writes:
> On 2010-03-16, heartsee1 <carolinabasaloalcid@gmail.com> wrote:
>> Been using google since itâ€™s started but I just heard google groups
>> yesterdayï Š
>> guys give you right to laughâ€¦ weird hah?
>>
>> Iâ€™m just so excited to explore this social network some moreâ€¦
>
> This is not a social network. It is a technical discussion
> group on Usenet. Please use only sentences containing both
> a subject and predicate, or C code.

Nor is it Google Groups. Google Groups provides a (rather clumsy)
interface to Usenet; Usenet existed for decades before Google was
founded.

If you want to discuss the C programming language, you're more than
welcome here.

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

== 3 of 7 ==
Date: Tues, Mar 16 2010 1:29 pm
From: "osmium"

heartsee1 wrote:

> Been using google since it's started but I just heard google groups
> yesterday?
> guys give you right to laugh. weird hah?
>
> I'm just so excited to explore this social network some more.
>
> Carolina

I can't tell if your post is real or not, I will respond as though it were
real. Usenet groups in general are not social networks at all. Google can
be very confusing because they also have somehing called google groups which
may well *be* social groups, I don't know. But you wandered, with the aid
of google, into a enet group. This group, especially, is toward the "empty"
end of the scale of friendliness.

For a Usenet social group try alt.fan.cecil-adams, but I warn you, very few
of the groups are intended to be social.

== 4 of 7 ==
Date: Tues, Mar 16 2010 1:38 pm
From: Ian Collins

On 03/17/10 09:01 AM, Andrew Poelstra wrote:
> On 2010-03-16, heartsee1<carolinabasaloalcid@gmail.com> wrote:
>> Been using google since it's started but I just heard google groups
>> yesterday
>> guys give you right to laugh… weird hah?
>>
>> I'm just so excited to explore this social network some more…
>>
>
> This is not a social network. It is a technical discussion
> group on Usenet. Please use only sentences containing both
> a subject and predicate, or C code.

Tell that to spinny!

--
Ian Collins

== 5 of 7 ==
Date: Tues, Mar 16 2010 2:05 pm
From: Keith Thompson

Ian Collins <ian-news@hotmail.com> writes:
> On 03/17/10 09:01 AM, Andrew Poelstra wrote:
>> On 2010-03-16, heartsee1<carolinabasaloalcid@gmail.com> wrote:
>>> Been using google since itâ€™s started but I just heard google groups
>>> yesterdayï Š
>>> guys give you right to laughâ€¦ weird hah?
>>>
>>> Iâ€™m just so excited to explore this social network some moreâ€¦
>>>
>>
>> This is not a social network. It is a technical discussion
>> group on Usenet. Please use only sentences containing both
>> a subject and predicate, or C code.
>
> Tell that to spinny!

What for?

== 6 of 7 ==
Date: Tues, Mar 16 2010 2:16 pm
From: Ian Collins

On 03/17/10 10:05 AM, Keith Thompson wrote:
> Ian Collins<ian-news@hotmail.com> writes:
>> On 03/17/10 09:01 AM, Andrew Poelstra wrote:
>>> On 2010-03-16, heartsee1<carolinabasaloalcid@gmail.com> wrote:
>>>> Been using google since itâ€™s started but I just heard google groups
>>>> yesterdayï Š
>>>> guys give you right to laughâ€¦ weird hah?
>>>>
>>>> Iâ€™m just so excited to explore this social network some moreâ€¦
>>>>
>>>
>>> This is not a social network. It is a technical discussion
>>> group on Usenet. Please use only sentences containing both
>>> a subject and predicate, or C code.
>>
>> Tell that to spinny!
>
> What for?

Your daily exercise in futility?

--
Ian Collins

== 7 of 7 ==
Date: Tues, Mar 16 2010 3:00 pm
From: Dr Malcolm McLean

On 16 Mar, 19:56, heartsee1 <carolinabasaloal...@gmail.com> wrote:
> Been using google since it's started but I just heard google groups
> yesterday
> guys give you right to laugh… weird hah?
>
> I'm just so excited to explore this social network some more…
>
> Carolina
>
Welcome Carolina,

The group is for C programmers, of all levels. We have beginners as
well as people who have authored C books here. Even Denis Ritchie has
been known to post occasionally.

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 11 ==
Date: Tues, Mar 16 2010 1:03 pm
From: Nick <3-nospam@temporary-address.org.uk>

Willem <willem@turtle.stack.nl> writes:

> Rod Pemberton wrote:
> ) What about "recase" or "reswitch"? E.g., perhaps like so:
> )
> ) case 0x10: recase (0x30);
> ) case 0x20: /* stuff */
> ) break;
> ) case 0x30: /* stuff */
> ) break;
> )
> ) The advantage is you don't need a goto label. The ordering can be as one
> ) wishes. And, each case could then be auto-break. Hmm, that's not too bad,
> ) IMO.
>
> I would prefer the 'see' keyword, and I would then recommend pointing back
> to earlier cases: It
>
> case 0x10: /* stuff */
> break; /*
> case 0x20: /* Other stuff */
> break;
> case 0x30: see case 0x10;
>
> Oh come on, it's too funny not to do it :P

It's rare for programming language discussion to cause a genuine LOL
moment, but that was one.

I've actually implemented something vaguely similar in my basic-like
homebrew language.

It has "select" statements with a controlling variable, which can be
changed. "next" functions inside "select" statements and causes the
whole switch to be started again.

So, for example:
for thisloop = 10 to 20 step 5
select thisloop as x
case x = 10
print 'hello'
x = 20
next x
case x = 15
print 'boo!'
case x = 20
print 'goodbye'
end select
end for thisloop

results in:
hello
goodbye
boo!
goodbye

I'm still not sure if this is a good idea or not.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 2 of 11 ==
Date: Tues, Mar 16 2010 1:13 pm
From: Seebs

On 2010-03-16, Nick <3-nospam@temporary-address.org.uk> wrote:
> Willem <willem@turtle.stack.nl> writes:
>> I would prefer the 'see' keyword, and I would then recommend pointing back
>> to earlier cases: It

>> case 0x10: /* stuff */
>> break; /*
>> case 0x20: /* Other stuff */
>> break;
>> case 0x30: see case 0x10;

>> Oh come on, it's too funny not to do it :P

> It's rare for programming language discussion to cause a genuine LOL
> moment, but that was one.

However, it's inappropriate for C.

It should be:

case 0x30: static case 0x10;

because "static" is the C keyword for "hey, guys, I have this great
idea..."

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

== 3 of 11 ==
Date: Tues, Mar 16 2010 1:29 pm
From: Andrew Poelstra

On 2010-03-16, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-03-16, Nick <3-nospam@temporary-address.org.uk> wrote:
>> Willem <willem@turtle.stack.nl> writes:
>>> I would prefer the 'see' keyword, and I would then recommend pointing back
>>> to earlier cases: It
>
>>> case 0x10: /* stuff */
>>> break; /*
>>> case 0x20: /* Other stuff */
>>> break;
>>> case 0x30: see case 0x10;
>
>>> Oh come on, it's too funny not to do it :P
>
>> It's rare for programming language discussion to cause a genuine LOL
>> moment, but that was one.
>
> However, it's inappropriate for C.
>
> It should be:
>
> case 0x30: static case 0x10;
>

I laughed at that one. :)

> because "static" is the C keyword for "hey, guys, I have this great
> idea..."
>
> -s

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

== 4 of 11 ==
Date: Tues, Mar 16 2010 2:50 pm
From: "Bartc"

Richard Delorme wrote:
> Le 15/03/2010 21:32, jacob navia a �crit :
>> Richard Delorme a �crit :
>>> - -> operator can be replaced by the . operator.

>> Maybe, but I find it clearer as it is now. You know that at the left
>> side of the name is a pointer, not an object.
>
> My code uses a lot of -> and I find it makes the code harder to read
> than a single dot.

I think C choose the wrong operator in "->": it combines the "*" dereference
op and the "." field select op in a new symbol that bears no resemblence to
either "*" or "."!

In Pascal, dereference is "^" (placed after the pointer), and field
selection is "." as in C.

These are combined in the obvious way: "^." as shown here:

struct pt {int x,y;} a;
struct pt *p;

C: Pascal:

a.x a.x X coord of a

*p p^ Entire struct pt
(*p).x p^.x X coord of *p
p->x p^.x X coord of *p

Proposal:

p.x Type error X coord of *p (NOT of p)

Allowing p.x as a synonym for p->x has been discussed here a few times. I
don't like it myself, although there are weak parallels with the way []
works on arrays, or pointers to arrays, and how () works with functions, or
pointers to functions.

I might compromise with "*." though:

p*.x

--
Bartc

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

== 5 of 11 ==
Date: Tues, Mar 16 2010 3:22 pm
From: "Bartc"

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

>> Binary only works well, IMO.
>
> Unless you need to handle text, of course. And no, manually handling
> the '\r' and '\n' characters is not a good solution, especially if
> your code might ever be ported to a system with a different text file
> format.

Even considering only systems using CR, CR/LF, or LF, C's text mode can go
wrong: reading in a file created on a computer with a different newline
sequence, or writing a text file on this computer and reading it on one
using a different sequence.

And then there are hybrid files which are mainly binary data, but also
contain embedded text that can include newline characters. Which means that
binary data that looks like CR/LF gets converted to LF (and the entire file
shrinks in size by one byte), or vice versa.

I suspect people who advocate text mode tend to use machines with a single
character newline, and simply don't see the problems it creates when newline
is multiple characters.

--
Bartc

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

== 6 of 11 ==
Date: Tues, Mar 16 2010 2:29 pm
From: Ian Collins

On 03/17/10 11:22 AM, Bartc wrote:
> Keith Thompson wrote:
>> "Rod Pemberton"<do_not_have@havenone.cmm> writes:
>
>>> Binary only works well, IMO.
>>
>> Unless you need to handle text, of course. And no, manually handling
>> the '\r' and '\n' characters is not a good solution, especially if
>> your code might ever be ported to a system with a different text file
>> format.
>
> Even considering only systems using CR, CR/LF, or LF, C's text mode can go
> wrong: reading in a file created on a computer with a different newline
> sequence, or writing a text file on this computer and reading it on one
> using a different sequence.
>
> And then there are hybrid files which are mainly binary data, but also
> contain embedded text that can include newline characters. Which means that
> binary data that looks like CR/LF gets converted to LF (and the entire file
> shrinks in size by one byte), or vice versa.
>
> I suspect people who advocate text mode tend to use machines with a single
> character newline, and simply don't see the problems it creates when newline
> is multiple characters.

I doubt that, on systems with a single character newline, test mode is
irrelevant.

--
Ian Collins

== 7 of 11 ==
Date: Tues, Mar 16 2010 3:36 pm
From: "Bartc"

Keith Thompson wrote:
> Richard Delorme <abulmo@nospam.fr> writes:

> Here's another example:
>
> === square.c ===
> float square(float x)
> {
> return x * x;
> }
>
> === main.c ===
> int main(void)
> {
> if (square(2.0) == 4.0) {
> return 0;
> }
> else {
> return 1;
> }
> }

> In your hypothetical C without "function forward declarations", how
> would this work? How would the compiler figure out that square()
> takes a float argument and returns a float result?

Many here seem to be confusing forward declarations, with external
declarations. I think Richard D was just questioning the necessity of a
function declaration, when the function *definition* exists elsewhere in the
file.

> I'm not saying it can't be done. I'm asking how you suggest doing it.

How would a person do it? You've given us a hint here, but placing square.c
next to main.c, so I'm assuming the square() in that file is the one in
question.

The compiler of main.c will need some extra information, such as the names
of some files to search for names which are undefined in main.c. And without
namespaces, it may have to search all the files suggested. In practice it
will likely build a database of exports from those files to speed things up.

The question you haven't asked, is how mutually recursive functions, one in
each of two modules (or perhaps in a circular chain of modules), are
handled. I'm still thinking about that one...

--
Bartc

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

== 8 of 11 ==
Date: Tues, Mar 16 2010 2:46 pm
From: Ian Collins

On 03/17/10 11:36 AM, Bartc wrote:
> Keith Thompson wrote:
>
>> I'm not saying it can't be done. I'm asking how you suggest doing it.
>
> How would a person do it? You've given us a hint here, but placing square.c
> next to main.c, so I'm assuming the square() in that file is the one in
> question.
>
> The compiler of main.c will need some extra information, such as the names
> of some files to search for names which are undefined in main.c. And without
> namespaces, it may have to search all the files suggested. In practice it
> will likely build a database of exports from those files to speed things up.

In other words a step backwards; requiring a two pass compilation.

> The question you haven't asked, is how mutually recursive functions, one in
> each of two modules (or perhaps in a circular chain of modules), are
> handled. I'm still thinking about that one...

That might take a while!

--
Ian Collins

== 9 of 11 ==
Date: Tues, Mar 16 2010 2:47 pm
From: Eric Sosman

On 3/16/2010 6:22 PM, Bartc wrote:
>
> Even considering only systems using CR, CR/LF, or LF, C's text mode can go
> wrong: reading in a file created on a computer with a different newline
> sequence, or writing a text file on this computer and reading it on one
> using a different sequence.

Okay, we agree: C's text streams are unsuitable for processing
files that are not text files. (This is news?)

On the other hand, C's binary streams are also unsuitable for
manipulating text in such files. I have used a real live system
(I believe the O/S in question is still in use and still supported
today) on which puts("Hello") produced

'\005' '\000' 'H' 'e' 'l' 'l' 'o' '\000'

If you moved those eight bytes verbatim to a Unix or Windows
system and tried to read them with a text stream, you'd get junk
at best. If you read them with a binary stream, you'd get the
eight bytes -- but then it would be *your* problem to know the
text-file conventions of the foreign system. (See the newline?
No? Too bad: It's there, sort of. See the two NUL's? Yes? Too
bad: They're not there, sort of.)

The solution is not for C to try to impose its own formatting
ideas on every system everywhere ("We control the horizontal, we
control the vertical"), but to find out and fix what went wrong
in the file transfer process. It's not C's fault that a malformed
file is malformed.

> And then there are hybrid files which are mainly binary data, but also
> contain embedded text that can include newline characters. Which means that
> binary data that looks like CR/LF gets converted to LF (and the entire file
> shrinks in size by one byte), or vice versa.

If you use the wrong kind of stream, you may get unwanted
translations (or miss out on necessary translations). The fix is
simple: Use the right kind of stream for the job at hand.

> I suspect people who advocate text mode tend to use machines with a single
> character newline, and simply don't see the problems it creates when newline
> is multiple characters.

This whole thing has been explained to you several times, and
you're still grasping the wrong end of the stick. C's distinction
between text and binary streams doesn't *create* incompatibilities,
it gives you a fighting chance to *solve* incompatibilities that
arise outside C's sphere of influence.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 10 of 11 ==
Date: Tues, Mar 16 2010 2:47 pm
From: Keith Thompson

"Bartc" <bartc@freeuk.com> writes:
> Keith Thompson wrote:
>> "Rod Pemberton" <do_not_have@havenone.cmm> writes:
>>> Binary only works well, IMO.
>>
>> Unless you need to handle text, of course. And no, manually handling
>> the '\r' and '\n' characters is not a good solution, especially if
>> your code might ever be ported to a system with a different text file
>> format.
>
> Even considering only systems using CR, CR/LF, or LF, C's text mode can go
> wrong: reading in a file created on a computer with a different newline
> sequence, or writing a text file on this computer and reading it on one
> using a different sequence.

So translate the file before trying to process it as text.

Such files are binary, and should be read in binary mode, which
always requires knowing the exact format of the file. If the format
specifies how the embedded text is represented, use that format.
If it doesn't, you're in trouble anyway.

> I suspect people who advocate text mode tend to use machines with a single
> character newline, and simply don't see the problems it creates when newline
> is multiple characters.

I'm quite aware of the problems; I deal with Unix-format
vs. Windows-format text files all the time (including ASCII, Latin-1,
Windows-1252, UTF-8, and both flavors of UTF-16). Some tools I use
can deal with the differences. For others, I use conversion tools.

== 11 of 11 ==
Date: Tues, Mar 16 2010 2:57 pm
From: Keith Thompson

"Bartc" <bartc@freeuk.com> writes:
> Keith Thompson wrote:
>> Richard Delorme <abulmo@nospam.fr> writes:
>
>> Here's another example:
>>
>> === square.c ===
>> float square(float x)
>> {
>> return x * x;
>> }
>>
>> === main.c ===
>> int main(void)
>> {
>> if (square(2.0) == 4.0) {
>> return 0;
>> }
>> else {
>> return 1;
>> }
>> }
>
>> In your hypothetical C without "function forward declarations", how
>> would this work? How would the compiler figure out that square()
>> takes a float argument and returns a float result?
>
> Many here seem to be confusing forward declarations, with external
> declarations. I think Richard D was just questioning the necessity of a
> function declaration, when the function *definition* exists elsewhere in the
> file.

That's why I asked Richard D to explain just what *he's* proposing.

[...]

==============================================================================
TOPIC: two C "style" questions
http://groups.google.com/group/comp.lang.c/t/f72ed27fa289d30e?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 16 2010 1:07 pm
From: Nick <3-nospam@temporary-address.org.uk>

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

> "generic callback functions" sometimes take a pointer-to-void, or a
> union of two members, a pointer-to-void and some integer. The
> pointer-to-void allows you to pass arbitrary parameters to the callback,
> packed in an "artificial" struct. Example from N1425:
>
> ----v----
> 7.24.5.1 The thrd_create function

Oh great, we're going to get a thrd_create function. What was wrong
with frst_create and secnd_create, eh?
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 2 of 2 ==
Date: Tues, Mar 16 2010 1:14 pm
From: Andrew Poelstra

On 2010-03-16, Nick <3-nospam@temporary-address.org.uk> wrote:
> lacos@ludens.elte.hu (Ersek, Laszlo) writes:
>
>> "generic callback functions" sometimes take a pointer-to-void, or a
>> union of two members, a pointer-to-void and some integer. The
>> pointer-to-void allows you to pass arbitrary parameters to the callback,
>> packed in an "artificial" struct. Example from N1425:
>>
>> ----v----
>> 7.24.5.1 The thrd_create function
>
> Oh great, we're going to get a thrd_create function. What was wrong
> with frst_create and secnd_create, eh?

We couldn't figure out how to unlock them.

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

==============================================================================
TOPIC: Does GCC optimize variadic functions to death?
http://groups.google.com/group/comp.lang.c/t/00b2bccdde28fde4?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 16 2010 1:21 pm
From: Elmar

Many thanks for all your comments!

I forgot to mention that I'm not a complete newbie (remember, I could
trace the problem on the assembler level ;-), so I did know about
va_list and friends.

> This is 100% wrong.
>
>
> You misspelled:
> void lst_print(int *list, ...)
> {
> va_list ap;
> int i;
> va_start(ap, list);
> for (i = 0; i < *list; ++i) {
> int val = va_arg(ap, int);
> printf("Value %d: %d\n", i, val);
> }
> }
>
>

The problem is that in real life, lst_print from my minimum example is
a much larger function, which I don't want to write twice, once as
shown originally (other functions need to call it with a list, not
with variable arguments), and once as typed out by you (would be a
nasty code duplication).

So the only correct alternative would be to turn val_print into a
wrapper for lst_print, and use va_start and va_arg to create a list
that is then passed to lst_print. This would require malloc/free etc.
to create an exact copy of what is already beautifully laid out on the
stack. My application is very performance critical, so creating
intermediate exact copies is something I usually try to avoid.

Portability is not my concern, since my application has >100000 lines
of assembler code and is tied to x86.

That's why I hoped there would be a simple trick to tweak the GCC
optimizer...

A few months from now, I'll be in trouble anyway, when it's time to
port to x86_64. There, va_start and va_arg are a true nightmare (the
assembler code is blown up and slowed down by a factor 2-3 since
variable arguments can end up in registers). So in case anyone has a
brilliant idea how to make my original example work on x86_64, you'll
be my hero!

Anyway, thanks!
Elmar

== 2 of 2 ==
Date: Tues, Mar 16 2010 1:29 pm
From: Seebs

On 2010-03-16, Elmar <elmar.krieger@gmail.com> wrote:
> I forgot to mention that I'm not a complete newbie (remember, I could
> trace the problem on the assembler level ;-), so I did know about
> va_list and friends.

In this case, knowing assembly is screwing you up -- you're assuming
that the function uses the same calling sequence all the time, but that's
not the case.

As an example, there has existed at least one system on which integer
and floating point arguments were collated -- the first floating point
argument would be in a particular register no matter how many integer
arguments there were.

> The problem is that in real life, lst_print from my minimum example is
> a much larger function, which I don't want to write twice, once as
> shown originally (other functions need to call it with a list, not
> with variable arguments), and once as typed out by you (would be a
> nasty code duplication).

Ahh, I see. So either it's passed as an array of objects, or a series
of arguments.

void
va_or_list_print(int use_va, int *list, va_list ap) {
int i;
for (i = 0; i < *list; ++i) {
printf("%d\n", use_va ? va_arg(ap, int) : list[i]);
}
}

void
va_print(int *count, ...) {
va_list ap;
va_start(ap, before_args);
va_or_list_print(1, count, ap);
va_end(ap);
}

void
list_print(int *items, ...) {
va_list ap;
va_start(items, ap);
va_or_list_print(0, items, ap);
va_end(ap);
}

The reason you need a '...' and a va_list for list_print is that you have
to be able to pass a valid va_list object to va_or_list_print.

Basically, you can pass another argument to the innermost function telling
it how to get its arguments. Then it'll work either way.

It ain't pretty, but I think it should work. As long as you can
make sure you always have a pointer to the number of arguments... But
you could do that in other ways, too:

void
va_print(int dummy, ...) {
int count = 0;
va_list_ap;
va_start(ap, dummy);
while (va_arg(ap, int) != -1)
++count;
va_end(ap, dummy);
va_start(ap, dummy);
va_or_list_print(1, &count, ap);
va_end(ap);
}

You can't get rid of that first argument, though. (But I suppose
you could make it a pointer, so you'd store the count of arguments
found before the sentinel in it.)

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

== 1 of 1 ==
Date: Tues, Mar 16 2010 1:27 pm
From: Ian Collins

On 03/17/10 07:27 AM, io_x wrote:
>
> #it is only one not conventional way of quote because my news reader not
> #show the ">" for your text and i would write manually all these">".

You are using a crap reader, google for "outlook quote fix".

--
Ian Collins

==============================================================================
TOPIC: Is allocating large objects on the stack a good practice?
http://groups.google.com/group/comp.lang.c/t/ce22843b03b7665b?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 16 2010 1:24 pm
From: William Ahern

Paavo Helde <myfirstname@osa.pri.ee> wrote:
<snip>
> Note also that in a multithreaded app each thread requires a separate
> stack, which at least for 32-bit programs means that by default the
> reserved stack size must be relatively small, and extra care must be
> taken to provide large stack only when creating some special threads -
> otherwise the 32-bit address space gets eaten up way too fast.

Perhaps this might catch on*

http://gcc.gnu.org/wiki/SplitStacks

I'm curious what the performance hit is, though. Perhaps GCC 4.5's link-time
optimizer could even optimize by attempting to deduce frame size
requirements.

Still, it's significantly more difficult to recover from out-of-memory
errors than using iterative algorithms.

* I don't think it will. AFAIK Ian started this work for the Google Go GCC
implementation, and I don't think it'll ever get enough attention as long
they continue to focus on their own native compiler.

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

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

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

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

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

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

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

twitter

Tuesday, March 16, 2010

comp.lang.c - 26 new messages in 7 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts