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

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: arithmetic on a void * pointer
http://groups.google.com/group/comp.lang.c/t/451b17d19dcc5236?hl=en
==============================================================================

== 1 of 6 ==
Date: Sat, Jan 9 2010 4:39 pm
From: "BGB / cr88192"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lniqbaoqdm.fsf@nuthaus.mib.org...
> "BGB / cr88192" <cr88192@hotmail.com> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:ln4omvoxb7.fsf@nuthaus.mib.org...
>>> "BGB / cr88192" <cr88192@hotmail.com> writes:
>>>> "Seebs" <usenet-nospam@seebs.net> wrote in message
>>>> news:slrnhkhdd6.351.usenet-nospam@guild.seebs.net...
>>>>> On 2010-01-09, Mark Adler <madler@alumni.caltech.edu> wrote:
>>> [...]
>>>>>> I would argue that alternatively we could eliminate this mixed
>>>>>> message
>>>>>> of void both implicitly having a size and not having a size by
>>>>>> changing
>>>>>> the C standard to give void a size, i.e. one. sizeof(void) == 1.
>>>>>> Nothing would break -- this would just add to the things that can be
>>>>>> expressed, in a way that is consistent with how library functions use
>>>>>> void * arguments. (The void type would still not be allowed by
>>>>>> itself,
>>>>>> and so function(void) would still mean no arguments.) In fact, in
>>>>>> the
>>>>>> evil gcc, n = sizeof(void); sets n to 1, and it seems to work fine.
>>>>>
>>>>> It works, but it's dumbing things down -- it's encouraging sloppy
>>>>> thinking
>>>>> about pointer types, and that ain't good.
>>>>
>>>> it makes sense to the CPU, and in the end, it is this which is what
>>>> matters.
>>>
>>> What matters more is what makes sense to the programmer and to the
>>> reader of the code. What matters is constructing a consistent model
>>> for computation, and letting the compiler map that model onto some
>>> particular hardware.
>>>
>>> If we only cared about what makes sense to the CPU, we wouldn't have
>>> more than a handful of types, all defined by the system, and portable
>>> code would be a pipe dream.
>>>
>>
>> granted, but these are still secondary, since if the CPU could not
>> understand the code or the data, the program would not run.
>>
>> no matter how elegant the conceptual model, it would be pointless to have
>> SW
>> which doesn't run...
>
> Sure, but the particular abstractions we're talking about, such as
> having void* be a raw pointer type that doesn't let you access what it
> points to without first converting the pointer, don't prevent the
> software from running. Implementers and programmers are entirely
> capable of writing working software using the abstractions defined by
> the C language.

granted.

however, C was also designed to run well on actual computers...

>>
>> the CPU is inescapable, as noted by how people may still end up needing
>> to
>> fall back to using assembler in many situations, and just the same, it is
>> sometimes / often needed to make use of these low-level details of how
>> data
>> is represented on particular HW to have much of any real hope of making
>> the
>> app work effectively...
>
> I don't think that's as common as you imply. I don't remember the
> last time I needed to resort to assembler. (For a lot of my own
> programming, I don't even resort to C, but that's another story.)
>

ASM is, in my case, my second most commonly used language (after C), the 3rd
is C++.
some also goes into very-specialized mini-languages (the most complex and
general of which, at this point, is my compilers' IL, but there are many
cases where I use very limited notations which usually drive specialized
state machines, ...).

many of these specialized mini-languages are used in close proximity to
machine code, either in encoding or decoding machine instructions, or in
some cases driving logic which essentially produces machine code from them.

most of my use of ASM is mixed up with the use of C, where a lot of C code
exists which produces ASM fragments (probably by far my largest-scale use of
ASM at this point).

it is fairly rare that I produce non-trivial amounts of standalone ASM code,
since for what I do, "ASM metaprogramming" is generally more useful.

the weak point though is that a lot of this code has to be either duplicated
or tweaked for every target (so, I don't often use it needlessly...).

use command strings to drive state-machines (typically specialized and
tweaked for a specific target or use) which produce ASM, which is in turn
sent to a dynamic assembler, which may parse it and produce machine code
(this process itself done with more specialized string-driven state
machines), and then linked into the running image. from this point, one may
fetch function pointers and call into the code, or maybe produce yet more
machine code from yet so many more strings...

apart from this, there are a few natural limitations to C which would be
very problematic to work around...

similarly, it is often very useful to be able to treat memory and data (and,
sometimes, machine code) as raw collections of bytes...

>> universal portability for non-trivial apps IS a "pipe dream", apart from
>> the
>> fact that luckily most HW tends to represent most things in similar
>> enough
>> ways that one can gloss over the details in the majority of cases (and
>> fall
>> back to good old "#ifdef" for most of the rest...).
>>
>> and so, abstraction is a tower built on top of the HW, and not the other
>> way
>> around.
>
> The abstraction level provided by standard C seems to be just about
> right for a lot of purposes, and I don't find that it gets in the way
> of writing efficient code in most cases. And in cases where it does,
> you can often write non-portable code, making additional
> implementation-specific assumptions, without leaving the language.
>
> I really wouldn't want to make C any lower level than it already is.
>

granted, but C is also one of the lower-level languages around...

it seemed to me like you were trying to invert the "grand ontology", as in,
another of those people who try to claim that computers are based on the
formal notions humans have about them, ... which to me seems absurd.

but, these types also tend to promote pure FPL's, such as Haskell, ...

I guess, it is the great thing where, as I see it, the basis of reality is
reality...

>> none of this really changes the end case, that in the end it is the CPU
>> which matters...
>>
>> if what were important were appeasing the mind of the reader of the code,
>> then people would be authors, not programmers, and the end result would
>> be a
>> novella, rather than a codebase...
>
> For the software I work on, I spend a lot more time maintaining it
> than running it. It's not a work of literature, but clarity and
> legibility are vitally important if I'm going to finish the job
> quickly enough for performance on the CPU to matter.
>

granted...

well, it is not like I am advocating writing tangled horrors of code either,
as I have also seen plenty of nasty enough code around.

but, I have also seen people try to promote "English-based" programming
languages, and have almost just as often seen these languages go nowhere...

maybe, it is that computers don't do English well, or, more likely, it is
that English is a very bad choice to try to base a programming language on.

but, if humans were in-fact the primary concern, then likely it would have
caught on regardless, considering how much easier of a time most people have
with English than with programming languages...

the fact that they have not, likely indicates that the primary concerns lie
elsewhere.

I personally suspect that it is the computer which remains primary...

humans adapt their mind to the computer, and not the computer around their
mind.

this is probably preferable anyways, as most peoples' minds are fluid and
vague, and it would probably suck if the everything were random and
ambiguous...

== 2 of 6 ==
Date: Sat, Jan 9 2010 5:58 am
From: "Dennis \(Icarus\)"

"Mark Adler" <madler@alumni.caltech.edu> wrote in message
news:2010010902080175249-madler@alumnicaltechedu...
<snip>
>
> I guess part of the problem is that void is a bit overloaded in C,

Not near as overloaded as static in C++ ;-)

> meaning a bunch of rather different things depending on the context:
<snip>
>
> Anyway, this has been enjoyable and instructive for me, so thank you all
> for your time. Some people seem to get a little ruffled in these
> religious discussions, so I hope I didn't offend anybody. So as to not
> waste any more of your time, I'll leave you alone and go back to working
> on the next release of zlib, which now has two occurences of buf = (char
> *)buf + n.

No offense taken at this end. Good luck with zlib.

Dennis

== 3 of 6 ==
Date: Sat, Jan 9 2010 7:37 pm
From: spinoza1111

On Jan 10, 3:43 am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <lnd41joyyk....@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
> ...
>
> >One thing that I find a bit offputting (I wouldn't say offensive)
> >is the idea that these discussions are "religious". C is just
> >a language; this newsgroup is, for me at least, just a hobby.
> >Very likely you're being facetious and I'm overreacting, but we've
> >had people here who really do treat this like a religious argument.
>
> And you are the prototype for it, and the prototypical instance.

Sure. The strategy being to say it's all a joke AFTER you've destroyed
people's reputations. They is just good old boys. They's just having
fun.

== 4 of 6 ==
Date: Sat, Jan 9 2010 8:00 pm
From: spinoza1111

On Jan 10, 3:20 am, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> spinoza1111 wrote:
> > On Jan 9, 11:16 pm, Mark <s...@not.welcome.here.ac.uk> wrote:
> >> spinoza1111 <spinoza1...@yahoo.com> wrote:
> >>> On Jan 9, 11:57 am, "Dennis \(Icarus\)" <nojunkm...@ever.invalid>
> >>> wrote:
> >>>> The C language is defined b the standard. Do you want to program in C or
> >>>> not?
> >>> No, from the standpoint of science (linguistics), no standard can
> >>> "define" C. This is because independent of the standard are all sorts
> >>> of C compilers with a fuzzy relation to any one formal definition of
> >>> C. Somewhat like world received English, C is what intelligent users
> >>> "say" it is. In addition, linguists also add that the language should
> >>> be the canonical user's first language, but this is impossible with C,
> >>> of course.
> >> Using norms from the realm of natural languages isn't necessarily
> >> helpful. Natural languages and computer languages share much in common,
> >> but much is not common. Indeed, you note one further down, when you
> >> point out that it would difficult for anyone to claim C as their first
> >> language.
>
> > OK, there are differences. However, the alternative (C as math or a
> > formal language) fails to fit the facts.
> >> Whilst it's true that (in line with natural languages) there are many
> >> dialects of C, programming languages are (I would argue) necessarily
> >> constrained by the need for programmers to agree very specific outcomes
> >> to very specific constructs; where (most) humans will happy handle (a
> >> certain level of) variation in usage and still be able to comprehend the
> >> essential meaning of the words, most computer languages and their
> >> execution environments struggle to be more than literal. As a result
> >> (and in my experience), languages which don't have formal definitions
> >> which implementations *try* to conform to tend to either exist in a
> >> monoculture (as single implementations) or fail to gain widespread
> >> adoption.
>
> > The problem is that C's "standardised formality" is bought by
> > simultaneously calling things undefined and permitting vendors to
> > continue to support the "undefined" concepts. C is simply not
> > formalized save in the most "Platonist" sense as opposed to the
> > "Intuitionist" sense, where Platonism in the philosophy of mathematics
> > is the belief that mathematical objects exist *in reality* whether or
> > not we know them, whereas Intuitionism is the belief that it doesn't
> > exist until it's constructed.
>
> > Now, it would seem that Intuitionism would be the philosophy of the
> > competent programmer.
>
> > [And at this point let me mention my sadness on hearing that Dik
> > Winter has passed away, for this type of statement is what he loved to
> > jump on: perhaps as a Dutch person he felt a special connection with
> > Intuitionism, and he always had something interesting to contribute to
> > the discussion, especially when I mentioned Brouwer or Dijkstra.]
>
> > Applying this to programming, to say "doing arithmetic on a void
> > pointer has no result" is Platonic since Adler showed (constructively
> > and in an intuitive/Intuitionist way) how this has a sensible meaning:
> > the sizeof a void pointer is the sizeof the smallest unit of memory.
>
> No it isn't. The sizeof any pointer is the number of bytes used to store
> a pointer value (generalised address). The size of a void* is required
> to be the same size as the size of a char*. On most systems it is 4 or
> 8. That is not the same as the size of the thing pointed to. And that

We know that.

> is the point, a void* object holds a location not the address of an

This is Scholastic pettifogging in service of the false proposition
that C is strongly typed. The location is the address. You're trying
to give a punning language a false respectability. C committs so many
crimes against common sense (such as the preprocessor) it wouldn't
hurt to allow void pointers of sizeof 4 or 8 on many machines,
pointing at the smallest addressable unit of storage, something with
sizeof==1. It would allow us to use C as a truly portable assembly
language. Not that I want to.

> object. If the programmer knows what is at that location they can
> convert the location information into an appropriate pointer value.
>
> This is not rocket science and is generally well understood by qualified
> computer scientists (i.w. those with CS degrees) who have learnt C.
>
> > It is Platonist to insist on the (unconstructed) possibility of an
> > alternative interpretation.
>
> No it isn't. Both Platonists and Intuitionists along with several other
> schools of mathematical philosophy well understand the difference
> between the container and the contents, the reference and the referee.

Hmm, there are only three according to Stefan Korner's out of print
survey: logicism-Platonism, Intuitionism, and formalism. Stewart
Shapiro (The Oxford Handbook of Philosophy of Mathematics and Logic)
lists only five: logicism, Mills' and Quine's empiricism, nominalism,
intuitionism and structuralism. I regard Korner's as the better
taxonomy as long as you add empiricism, better in the sense of being
mutually exclusive and exhaustive.

The existence or nonexistence of personae who well understand is a
rather shadowy argument, that uses poppets to "prove" that
everything's under control. The question is whether you can understand
in the sense of explain.

Most American universities socialize their students into Platonism (cf
Robert M Pirsig's experience at the University of Chicago as
documented in Zen and the Art of Motorcycle Maintenance). This is
because to function in the world as upper middle class high earners,
the students must accept the existence of Platonic Ideas in the form
of immortal corporations with actual human rights under the Fourteenth
Amendment.

This causes people here to treat any sort of assertion *with which
they agree* as of equal value with more informative and intuitionist-
in-the-sense-of-constructive assertions. It's why it's the height of
wisdom to groan that something's "undefined" and that one may not
assign void pointers a dereferencing meaning.

== 5 of 6 ==
Date: Sat, Jan 9 2010 8:04 pm
From: Kaz Kylheku

On 2010-01-09, Mark Adler <madler@alumni.caltech.edu> wrote:
> On 2010-01-08 22:59:53 -0800, Beej Jorgensen said:
>
>> On 01/08/2010 08:12 PM, Mark Adler wrote:
>>> My current copy of gcc (4.2.1) will, with all warnings enabled (-Wall)
>>> is perfectly happy with (no warnings):
>>>
>>> void *buf;
>>> int n;
>>>
>>> buf += n;
>>
>> gcc -pedantic:
>>
>> foo.c:9: warning: pointer of type 'void *' used in arithmetic
>>
>> Perhaps it's only warning idiots like me? ;-)
>
> Apparently -Wall really only means -Wsome.

Hypothesis: maybe, in the ancient early history of GCC, that's in
fact what it meant. Then maybe then new warnings crept into the code
and developers realized that they don't want the -Wall option to
actually turn on some of these new ones, because among them there are
false positives: warnings about situations that don't necessarily need
to be fixed. Nobody bothered to rename -Wall to -Wsome, or
-Whouse-special-combo.

== 6 of 6 ==
Date: Sat, Jan 9 2010 8:12 pm
From: spinoza1111

On Jan 10, 6:38 am, Keith Thompson <ks...@mib.org> wrote:
> "BGB / cr88192" <cr88...@hotmail.com> writes:
>
>
>
>
>
> > "Keith Thompson" <ks...@mib.org> wrote in message
> >news:ln4omvoxb7.fsf@nuthaus.mib.org...
> >> "BGB / cr88192" <cr88...@hotmail.com> writes:
> >>> "Seebs" <usenet-nos...@seebs.net> wrote in message
> >>>news:slrnhkhdd6.351.usenet-nospam@guild.seebs.net...
> >>>> On 2010-01-09, Mark Adler <mad...@alumni.caltech.edu> wrote:
> >> [...]
> >>>>> I would argue that alternatively we could eliminate this mixed message
> >>>>> of void both implicitly having a size and not having a size by changing
> >>>>> the C standard to give void a size, i.e. one. sizeof(void) == 1.
> >>>>> Nothing would break -- this would just add to the things that can be
> >>>>> expressed, in a way that is consistent with how library functions use
> >>>>> void * arguments. (The void type would still not be allowed by itself,
> >>>>> and so function(void) would still mean no arguments.) In fact, in the
> >>>>> evil gcc, n = sizeof(void); sets n to 1, and it seems to work fine.
>
> >>>> It works, but it's dumbing things down -- it's encouraging sloppy
> >>>> thinking
> >>>> about pointer types, and that ain't good.
>
> >>> it makes sense to the CPU, and in the end, it is this which is what
> >>> matters.
>
> >> What matters more is what makes sense to the programmer and to the
> >> reader of the code. What matters is constructing a consistent model
> >> for computation, and letting the compiler map that model onto some
> >> particular hardware.
>
> >> If we only cared about what makes sense to the CPU, we wouldn't have
> >> more than a handful of types, all defined by the system, and portable
> >> code would be a pipe dream.
>
> > granted, but these are still secondary, since if the CPU could not
> > understand the code or the data, the program would not run.
>
> > no matter how elegant the conceptual model, it would be pointless to have SW
> > which doesn't run...
>
> Sure, but the particular abstractions we're talking about, such as
> having void* be a raw pointer type that doesn't let you access what it
> points to without first converting the pointer, don't prevent the
> software from running. Implementers and programmers are entirely
> capable of writing working software using the abstractions defined by
> the C language.
>
>
>
> > the CPU is inescapable, as noted by how people may still end up needing to
> > fall back to using assembler in many situations, and just the same, it is
> > sometimes / often needed to make use of these low-level details of how data
> > is represented on particular HW to have much of any real hope of making the
> > app work effectively...
>
> I don't think that's as common as you imply. I don't remember the
> last time I needed to resort to assembler. (For a lot of my own
> programming, I don't even resort to C, but that's another story.)
>
> > universal portability for non-trivial apps IS a "pipe dream", apart from the
> > fact that luckily most HW tends to represent most things in similar enough
> > ways that one can gloss over the details in the majority of cases (and fall
> > back to good old "#ifdef" for most of the rest...).
>
> > and so, abstraction is a tower built on top of the HW, and not the other way
> > around.
>
> The abstraction level provided by standard C seems to be just about
> right for a lot of purposes, and I don't find that it gets in the way
> of writing efficient code in most cases. And in cases where it does,
> you can often write non-portable code, making additional
> implementation-specific assumptions, without leaving the language.
>
> I really wouldn't want to make C any lower level than it already is.
>
> > none of this really changes the end case, that in the end it is the CPU
> > which matters...
>
> > if what were important were appeasing the mind of the reader of the code,
> > then people would be authors, not programmers, and the end result would be a
> > novella, rather than a codebase...
>
> For the software I work on, I spend a lot more time maintaining it
> than running it. It's not a work of literature, but clarity and
> legibility are vitally important if I'm going to finish the job
> quickly enough for performance on the CPU to matter.

Programmerese and boilerplate. Since 1970, EVERY programmer has made
this claim. It starts with the disclaimer that OF COURSE it isn't
"literature" or any girlie stuff (why not) and rolls on to the claim
that the speaker is terribly interested in writing clear and legible
code. In making the claim, the writer or speaker often uses English in
a way that shows he hasn't fully mastered that language, the mastery
of which was thought by Dijkstra to be a prerequisite for mastering
programming.

Here, for example, Kiki says he writes "legible" code. But "legible"
means readable hand-writing! The last time it mattered that one writes
"legibly" was when we prepared Cobol on green and white coding sheets
for the lovely ladies of the keypunch room.

This is a subtle error, like claiming that Schildt is "clear but
false", but it's noticed by the careful reader.

And, just as we start with the necessary disclaimer that one is not
being so presumptuous and "disruptive" as to write Great Literature,
one ends with the absolute value of time to market as linked under the
rose with the time value of money, which rules our lives so savagely.

This sort of language paces out a space within a prison cell
constructed by economic relations which in the USA could have been
questioned long ago and today are in the process of collapse. The
result is the twisted lower middle class resentment that believes that
it, the lower middle class subject, has been virtuous for naught,
grinding away writing clear and legible code whilst elsewhere welfare
bums and dancing trolls chortle at him amongst the burning tyres.
>
> --
> Keith Thompson (The_Other_Keith) ks...@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"

==============================================================================
TOPIC: code questions
http://groups.google.com/group/comp.lang.c/t/7a3cef83a72aada6?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 9 2010 4:47 pm
From: "Bill Cunningham"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnaawoqggv.fsf@nuthaus.mib.org...
> Look on page 263 (the first page of the index), about 2/3 of the way
> down the first column, between "&&" and "||".

Aha. a logical not then. I was confusing it with != when if (!something)
is more like if (||something).

Bill

== 2 of 2 ==
Date: Sat, Jan 9 2010 7:18 pm
From: Keith Thompson

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnaawoqggv.fsf@nuthaus.mib.org...
>> Look on page 263 (the first page of the index), about 2/3 of the way
>> down the first column, between "&&" and "||".
>
> Aha. a logical not then. I was confusing it with != when if (!something)
> is more like if (||something).

Yes, it's logical not.

!= is in equality; it's a single token, obviously inspired by the use
of "!" to mean negation, but defined by itself.

"if (||something)" doesn't make any sense; I have no idea what point
you're trying to make by mentioning it.

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

==============================================================================
TOPIC: Is this auction possible in SAYC?
http://groups.google.com/group/comp.lang.c/t/3b2541a375ca978e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 9 2010 4:49 pm
From: "Fred."

On Jan 9, 2:22 pm, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <b01ac576-e537-4e62-ae69-760a885d9...@h9g2000yqa.googlegroups.com>,Fred. <ghrno-goo...@yahoo.com> wrote:
>
> ...
>
> >My inference was that since the question was if the auction was
> >possible in SAYC, it referred to the pamplet. Otherwise, to me the
> >question would seem empty with an obvious "yes" for an answer.
>
> I see what you are saying, but I have tried to make it clear that my
> questions are never to be interpreted as being strictly exercises in
> hermeneutics of the SAYC text. I'm more interested in the practical
> side of things - "SAYC as she is spoke". And in the "as she is spoke"
> category, the question is still meaningful - a system can be quite
> sensible and playable and still be referred to as SAYC even though it
> does not agree with the document. Equally clearly (and addressing
> specifically your point), a system could be referred to as SAYC and be
> neither sensible nor playable.
>
> Now, I grant that anytime someone makes a comment like that (i.e., like
> the above paragraph), one is making an implicit charge that the document
> is flawed and needs to be fixed. However, in real life we all know that
> adapting and changing "how she is spoke" is easier and more practical
> than is changing the document.
>
> And, of course, these same comments apply even more forcefully to the "C
> standards" documents...

Sorry. I thought perhaps it was a practical question about how to
live within the scope of the pamphlet.

There obviously is a problem making a 2 over 1 response with just any
10 HCP when it promises a rebid. Personally, I would rather have at
least 12 HCP or a 6-card suit if my 2/1 has absolutely promised a
rebid, and sometimes even that isn't enough.

I shade the bad 10 into 1NT allowing the auction you speak of to
occur. I also treat opener's minimum rebid of the opening suit as
releasing responder from the rebid promise if the hand is starting to
look like a bad fit. Surprisingly, these practices have not yet
earned me a lecture. But, I don't play SAYC enough establish a
partnership understanding or to speak for "standard" practice.

Fred.

==============================================================================
TOPIC: plz send me the solution of the problem.
http://groups.google.com/group/comp.lang.c/t/2b0df2dd5d20b8c8?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 9 2010 6:53 pm
From: pete

wahid wrote:
> Write a program that will have an integer
> number input, and show the digits seperately.
> (Assume that no number with more than 3
> digits will be present in the input)
>
> like :
> � Enter a Number: 942
> � The first digit of the number is : 9
> � The second digit of the number is : 4
> � The third digit of the number is : 2

/* BEGIN new.c */

#include <stdio.h>

#define MAX 999
#define str(x) # x
#define xstr(x) str(x)

int main(void)
{
int d;
char array[sizeof xstr(MAX)];
char *string[] = {"first","second","third"};

fputs("Enter an integer from 0 to " xstr(MAX) ": ", stdout);
fflush(stdout);
if (fscanf(stdin, "%d", &d) == 1 && d >= 0 && MAX >= d) {
sprintf(array, "%d", d);
for (d = 0; array[d] != '\0'; ++d) {
printf("The %-6s digit of the number is : %c\n",
string[d], array[d]);
}
} else {
puts("Try again.");
}
return 0;
}

/* END new.c */

--
pete

== 2 of 2 ==
Date: Sat, Jan 9 2010 11:01 pm
From: wahid

thank you .

==============================================================================
TOPIC: order of printf
http://groups.google.com/group/comp.lang.c/t/6213d774d63f446a?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Jan 9 2010 7:15 pm
From: Keith Thompson

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
>>> The output /is/ flushed (in this example, at least). What is
>>> implementation defined is the effect of a final output line with no
>>> '\n' at the end (which is one possible outcome).
>>
>> No, what is implementation defined is whether the '\n' at the end the
>> output is required. If the implementation says it's not required, the
>> output is flushed when the program terminates, and the behavior is
>> well defined (though what the environment does with the output might
>> not be). If the implementation says it is required, then the behavior
>> of the program is undefined, simply because the standard doesn't
>> define the behavior. (The implementation may, but isn't required to,
>> define the behavior anyway.)
>
> I am not persuaded that a program's behaviour is undefined in the
> specific case where an implementation requires a newline at the end of
> the output and none is present. Can you say more about why you
> believe it is?
>
> I know it is not normative, but wouldn't you expect this case to be
> listed in sec. 2 of Appendix J if the intent were for such programs to
> have undefined behaviour?
>
> Your argument is that the standard does not define the behaviour, but
> would say that is does. I would say that it defines the behaviour of
>
> #include <stdio.h>
>
> int main(void) { printf("No newline"); }
>
> as well as it possibly can, regardless of any extra requirements that
> the implementation may put on the stream.

What else could it mean for an implementation to "require" the
newline to be present?

The standard allows an implementation to impose a certain
requirement, that the last line of a text stream must have a
terminating newline character. But it says nothing about how this
requirement might be enforce, or, equivalently, about what happens
if a program violates the requirement. It doesn't even say that
the resulting behavior is implementation-defined; it just fails to
define it.

I can imagine your program on such an implementation not writing
the last line, writing only a partial line, implicitly appending a
newline (because the underlying system requires it), having printf
return a negative value to indicate an error, or creating a corrupted
text file that can't be read. I see nothing in the standard that
forbids any of those behavior, or any other behavior.

Perhaps it wasn't intended to make the behavior undefined (the
omission from Annex J is telling), but in the absence of any
definition of the behavior, I'd say the behavior is undefined.

If it's defined, how would you say it's defined?

== 2 of 3 ==
Date: Sat, Jan 9 2010 8:37 pm
From: Ben Bacarisse

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>>>> The output /is/ flushed (in this example, at least). What is
>>>> implementation defined is the effect of a final output line with no
>>>> '\n' at the end (which is one possible outcome).
>>>
>>> No, what is implementation defined is whether the '\n' at the end the
>>> output is required. If the implementation says it's not required, the
>>> output is flushed when the program terminates, and the behavior is
>>> well defined (though what the environment does with the output might
>>> not be). If the implementation says it is required, then the behavior
>>> of the program is undefined, simply because the standard doesn't
>>> define the behavior. (The implementation may, but isn't required to,
>>> define the behavior anyway.)
>>
>> I am not persuaded that a program's behaviour is undefined in the
>> specific case where an implementation requires a newline at the end of
>> the output and none is present. Can you say more about why you
>> believe it is?
>>
>> I know it is not normative, but wouldn't you expect this case to be
>> listed in sec. 2 of Appendix J if the intent were for such programs to
>> have undefined behaviour?
>>
>> Your argument is that the standard does not define the behaviour, but
>> would say that is does. I would say that it defines the behaviour of
>>
>> #include <stdio.h>
>>
>> int main(void) { printf("No newline"); }
>>
>> as well as it possibly can, regardless of any extra requirements that
>> the implementation may put on the stream.
>
> What else could it mean for an implementation to "require" the
> newline to be present?

My view is that it would be up to the implementation what it means but
that that meaning is beyond the reach of the C standard. Had the
committee intended to make such situations undefined I think they
would have said so. They want to give permission for an implementation
to "mess up" in this case (provided it documents that it might) but
they don't want to say any more than that. It would have been so easy
to add another instance if UB explicitly at this point that the
absence is, to me, telling.

> The standard allows an implementation to impose a certain
> requirement, that the last line of a text stream must have a
> terminating newline character. But it says nothing about how this
> requirement might be enforce, or, equivalently, about what happens
> if a program violates the requirement. It doesn't even say that
> the resulting behavior is implementation-defined; it just fails to
> define it.

I don't think it is so clear-cut. It fails to define the consequences
of a requirement.

> I can imagine your program on such an implementation not writing
> the last line, writing only a partial line, implicitly appending a
> newline (because the underlying system requires it), having printf
> return a negative value to indicate an error, or creating a corrupted
> text file that can't be read. I see nothing in the standard that
> forbids any of those behavior, or any other behavior.

I think my program must do all the things specified for a similar
program that has a putchar('\n'); after the printf except it does not
do the putchar. At least that seems to me a reasonable reading of the
standard. I agree with most of your possibilities except the last
one: "any other behaviour".

It all boils down to whether something that the implementation
requires is as significant as something the standard requires.

> Perhaps it wasn't intended to make the behavior undefined (the
> omission from Annex J is telling), but in the absence of any
> definition of the behavior, I'd say the behavior is undefined.
>
> If it's defined, how would you say it's defined?

By the sections covering printf, program termination and so on.
Characters are transmitted to the host environment, but because they
do not meet a requirement of the implementation, the host environment
is permitted to do pretty much anything it like with it. I don't see
that it is permitted to anything not related to that data.

I am aware that this is a less than satisfactory argument.

--
Ben.

== 3 of 3 ==
Date: Sat, Jan 9 2010 10:01 pm
From: Keith Thompson

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>>>> The output /is/ flushed (in this example, at least). What is
>>>>> implementation defined is the effect of a final output line with no
>>>>> '\n' at the end (which is one possible outcome).
>>>>
>>>> No, what is implementation defined is whether the '\n' at the end the
>>>> output is required. If the implementation says it's not required, the
>>>> output is flushed when the program terminates, and the behavior is
>>>> well defined (though what the environment does with the output might
>>>> not be). If the implementation says it is required, then the behavior
>>>> of the program is undefined, simply because the standard doesn't
>>>> define the behavior. (The implementation may, but isn't required to,
>>>> define the behavior anyway.)
>>>
>>> I am not persuaded that a program's behaviour is undefined in the
>>> specific case where an implementation requires a newline at the end of
>>> the output and none is present. Can you say more about why you
>>> believe it is?
>>>
>>> I know it is not normative, but wouldn't you expect this case to be
>>> listed in sec. 2 of Appendix J if the intent were for such programs to
>>> have undefined behaviour?
>>>
>>> Your argument is that the standard does not define the behaviour, but
>>> would say that is does. I would say that it defines the behaviour of
>>>
>>> #include <stdio.h>
>>>
>>> int main(void) { printf("No newline"); }
>>>
>>> as well as it possibly can, regardless of any extra requirements that
>>> the implementation may put on the stream.
>>
>> What else could it mean for an implementation to "require" the
>> newline to be present?
>
> My view is that it would be up to the implementation what it means but
> that that meaning is beyond the reach of the C standard. Had the
> committee intended to make such situations undefined I think they
> would have said so. They want to give permission for an implementation
> to "mess up" in this case (provided it documents that it might) but
> they don't want to say any more than that. It would have been so easy
> to add another instance if UB explicitly at this point that the
> absence is, to me, telling.

"Beyond the reach of the C standard" is *exactly* what "undefined
behavior" means. It doesn't mean that the program will misbehave in
some gruesome manner; it merely means that the standard doesn't say
how it behaves.

See also C99 4p2:

If a ''shall'' or ''shall not'' requirement that appears outside
of a constraint is violated, the behavior is undefined. Undefined
behavior is otherwise indicated in this International Standard by
the words ''undefined behavior'' or by the omission of any
explicit definition of behavior. There is no difference in
emphasis among these three; they all describe ''behavior that is
undefined''.

>> The standard allows an implementation to impose a certain
>> requirement, that the last line of a text stream must have a
>> terminating newline character. But it says nothing about how this
>> requirement might be enforce, or, equivalently, about what happens
>> if a program violates the requirement. It doesn't even say that
>> the resulting behavior is implementation-defined; it just fails to
>> define it.
>
> I don't think it is so clear-cut. It fails to define the consequences
> of a requirement.

It "fails to define" (i.e., leaves undefined) the consequences (i.e.,
the behavior).

>> I can imagine your program on such an implementation not writing
>> the last line, writing only a partial line, implicitly appending a
>> newline (because the underlying system requires it), having printf
>> return a negative value to indicate an error, or creating a corrupted
>> text file that can't be read. I see nothing in the standard that
>> forbids any of those behavior, or any other behavior.
>
> I think my program must do all the things specified for a similar
> program that has a putchar('\n'); after the printf except it does not
> do the putchar. At least that seems to me a reasonable reading of the
> standard.

That would be the required behavior for an implementation that
*doesn't* require the trailing newline.

> I agree with most of your possibilities except the last
> one: "any other behaviour".

But most of the possibilities I mentioned are inconsistent with what
you just said.

> It all boils down to whether something that the implementation
> requires is as significant as something the standard requires.
>
>> Perhaps it wasn't intended to make the behavior undefined (the
>> omission from Annex J is telling), but in the absence of any
>> definition of the behavior, I'd say the behavior is undefined.
>>
>> If it's defined, how would you say it's defined?
>
> By the sections covering printf, program termination and so on.
> Characters are transmitted to the host environment, but because they
> do not meet a requirement of the implementation, the host environment
> is permitted to do pretty much anything it like with it. I don't see
> that it is permitted to anything not related to that data.

I don't see anything that says the consequences are limited to those
related to that data.

The behavior isn't unspecified, because the standard doesn't provide
two or more possibilities. It isn't implementation-defined, because
the standard doesn't require the implementation to document the
behavior, only to document whether the newline is required.

> I am aware that this is a less than satisfactory argument.

Agreed. 8-)}

==============================================================================
TOPIC: Comparision of C Sharp and C performance
http://groups.google.com/group/comp.lang.c/t/4cf78a2afa73b77a?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Jan 9 2010 8:30 pm
From: spinoza1111

On Jan 10, 1:19 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Jan 9, 10:33 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
> >> > On Jan 7, 11:08 am, Seebs <usenet-nos...@seebs.net> wrote:
> >> >> On 2010-01-07, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> >> >> > ... For example, listing 10 in chapter 10 shows:
>
> >> >> > #define ABS(a) (a) < 0 ? -(a) : (a)
>
> >> >> > which might be there to show how /not/ to write a macro (please tell
> >> >> > me it is).
>
> >> >> You lose.
>
> >> >> "When this program is compiled, a in the macro definition will be
> >> >> substituted with the values -1 and 1. The parentheses that enclose
> >> >> a ensure proper substitution in all cases. For example, if the
> >> >> parentheses around a were removed, this expression:
> >> >> ABS(10-20)
> >> >> would be converted to
> >> >> 10-20 < 0 ? -10-20 : 10-20
> >> >> after macro replacement and would yield the wrong result."
>
> >> >> So, yeah, "all cases" meaning "all cases where the macro is not used in a
> >> >> larger expression".
> <snip>
> >> Why would
> >> someone suggest that ABS might be written that way? It will trip
> >> every beginner up.
>
> > Herb should have known the rule; he probably did know the rule.
> > However, most of his audience works in shops where rules in excess of
> > the language are known as "standards", and in these shops, employees
> > who cultivate their own approaches (including approaches that might be
> > recommended by people who consider themselves hotshots) are terminated
> > as "not part of the team". Therefore, it seems that Schildt and/or his
> > editors decided not to include a variety of "coding standards" that
> > have evolved because of the poor design of C.
>
> What logic lead him to cover one important aspect of function-like
> macros (putting parentheses round the parameters) and exclude another
> (parentheses round the whole expression)? It look to me like a simple
> mistake.

He didn't want to explain "my" 1990 rule (parenthesize formal
parameters in macro definitions, decide whether to return an
expression or a statement, return nothing else, if you return an
expression return it in its own set of round parentheses, if you
return a statement return the statement list in its own set of braces)
because there might have been counter-examples and the rule is rather
complicated.

To be able to understand it, the programmer has to know the difference
between a formal and an actual parameter and Herb could not assume
this knowledge in his readers.

It occured to me when in 1987 I used the preprocessor heavily to
create usable strings (based on the model of Rexx) and it is not the
sort of thing that occurs to C programmers without my experience in
other languages, which at the time included direct machine language,
assembler, Fortran, Cobol, PL.1, Pascal, Basic, theoretical Algol and
Rexx. It would have been too hard for Herb to explain to the entry-
level reader and it would have contradicted the readers' own
experience: it is not a rule that is in general use.

Although useful, it was basically just another neurotic tic (such as
being proud of returning something nice to the OS in a main
procedure), although taking excess pride in what you return in main()
is far more pathological since it results from thinking of the OS as a
Lacanian Big Other. Acceptable languages do not need programmers to
develop neurotic patterns of behavior.

>
> <snip>
>
> >> Code like that does not help anyone who has to deal with C in a real
> >> job. People like that need correct examples and models of good
> >> style. Why, for example, is he using 'gets'; C's worst function (and
> >> an officially deprecated one) if he is just trying to help people muddle
> >> though with this terrible language?
>
> > Don't blame Herb for the cowardice of C standards writers who won't
> > get rid of bad features once and for all when this might harm the
> > profits of vendors.
>
> It's gone. The next C standard will not have gets. If there is ever
> a 5th edition, presumably the code will be corrected to remove
> repeated use of a deprecated function (85 uses).

Pray, what is gets() replaced with?
>
> But that is not the point. The world is changed by education not
> standards committees. Educators should take the lead in teaching the
> best practise.

They do. They say "don't use C, use Java". Educators must NOT allow
their agenda to be set by greedy corporations or little C coders.
Their job in computer science is to prepare people who can think
CRITICALLY and TALK BACK to Fat Bastards in corporations who say that
C, or awk, or RPG or ourveryownlanguagewhichsucks are the greatest
thing since oral sex. And as it happens, people who hate C sometimes
program rings around C lovers precisely because they know how it
sucks.
>
> <snip>
> --
> Ben.

== 2 of 4 ==
Date: Sat, Jan 9 2010 8:34 pm
From: spinoza1111

On Jan 9, 11:46 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111wrote:
> > On Jan 9, 5:04 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> spinoza1111wrote:
> >>> On Jan 9, 10:33 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> <snip>
>
> >>>> I think you've missed the point. The parentheses around (a) are not
> >>>> the issue because they are, of course, correct. The problem is the
> >>>> lack of parentheses around the conditional expression.
> >>> Correctomundo: the conditional expression violates "my" rule, which I
> >>> developed in 1990, that "each macro that intends to return an
> >>> EXPRESSION must return an EXPRESSION surrounded by PARENTHESES: each
> >>> macro that intends to return a STATEMENT must return a STATEMENT LIST
> >>> surrounded by BRACES".
> >> Macros don't return either expressions or statements.
>
> > Then you misunderstand their proper use despite your "expertise" in C.
>
> It's possible, but I don't think it very likely.
>
> > If a macro returns anything else besides an expression or statement it
> > can cause errors.
>
> Macros don't return expressions, statements, or *anything else*.

Yes they do. When they are evaluated, they return a fully substituted
string. You really need to learn the relationship between the ways
functions are evaluated at run time and macros are evaluated at
preprocessor time because the similarities and differences are
fundamental computer science.
>
> <snip>
>
> >> Functions return expressions (never statements).
>
> > Wow, I'll alert the media. Functions return expressions? This is
> > nonsense. Functions return the values of expressions.
>
> Right. Well done. I misspoke, and you caught me. That's one brownie
> point to you. Treasure it.

When I stumble, Homer farts: when you stumble, Homer Simpson farts. I
am however willing to accept for the moment that you made a simple
mistake, as opposed to your deliberate lie that I wasn't in
comp.risks. I will take it out of the Red Book. Go and sin no more.

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

== 3 of 4 ==
Date: Sat, Jan 9 2010 8:45 pm
From: spinoza1111

On Jan 9, 10:47 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> spinoza1111wrote:
> > On Jan 9, 5:04 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> spinoza1111wrote:
> >>> On Jan 9, 10:33 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> <snip>
>
> >>>> I think you've missed the point. The parentheses around (a) are not
> >>>> the issue because they are, of course, correct. The problem is the
> >>>> lack of parentheses around the conditional expression.
> >>> Correctomundo: the conditional expression violates "my" rule, which I
> >>> developed in 1990, that "each macro that intends to return an
> >>> EXPRESSION must return an EXPRESSION surrounded by PARENTHESES: each
> >>> macro that intends to return a STATEMENT must return a STATEMENT LIST
> >>> surrounded by BRACES".
> >> Macros don't return either expressions or statements.
>
> > Then you misunderstand their proper use despite your "expertise" in C.
> > If a macro returns anything else besides an expression or statement it
> > can cause errors. It can also cause errors if it is restricted by
> > outer parentheses or brackets to returning expressions-as-text or
> > statements-as-text, but this reduces the error space.
>
> For someone who claims expertise in English your reading skills leave
> much to be desired. A C pre-processor macro (which would be the default
> use for the word 'macro' in this newsgroup) does not return anything; it
> causes a textual substitution in the source code.

(Sigh) Look inside the preprocessor, or write one as a class project
in a computer science class.

You will in fact see the macro processor "returning" a fully
substituted string, which is the value of the macro when supplied with
actual parameters.

Understanding both the differences and commonality between function
evaluation at run time and macro substitution helps to understand why
the two forms of "subroutine" can be interchanged in certain cases.
Being able to explain it is fundamental to being a literate computer
scientist, whereas low-level technicians have this ability beaten out
of them in the corporation lest they "disruptively" transform a
function into a macro or vice-versa (or to or from an inline) thus
exceeding their remit.

There are indeed forms of English I have not mastered. One is the tone
of the authoritarian bully. Another is the ability to collapse trees
into vectors in the sense of replacing structure with the rows of
meaningless boxes that confront the alienated clerk.
>
>
>
> >> They represent
> >> user-defined rules for relatively simple textual substitutions.
> >> Functions return expressions (never statements).
>
> > Wow, I'll alert the media. Functions return expressions? This is
> > nonsense. Functions return the values of expressions. I'd say you're
> > thinking of Lisp, but you probably know less about Lisp than you know
> > about the high concepts of C as opposed to coding details and trivia.
>
> > I suppose a function could return a pointer to a function and this
> > could be called (painfully) "returning an expression", but for a C
> > function to return an unevaluated expression? It'd have to return the
> > source code and the user would have to call a C compiler!
>
> 1) In the terminology of C (and that is what we discuss here) a value is
> a (trivial) expression.
> 2) the return statement in the body of the code does indeed return a(n
> evaluated) expression.
>
>
>
> > That's one for the Heathfield tab of the Red Book, along with "Nilges
> > was never accepted to post at Comp.risks" and over in the Seebie tab,
> > "the 'heap' is a DOS term".
>
> Your behaviour is typical of the playground bully. You continue to use
> quotes to taunt people.

Only when some ASSHOLE here starts in on me or one of my colleagues,
switching the discussion to the bona fides and competence of his
interlocutor when bested in a technical or social discussion. But a
Tom Brown who fights back, especially against not just Flashman but
the whole upper form, is not a bully.

The first quote was a deliberate and malicious lie. The second a silly
error made in a document that accused Schildt of errors.
>
>
>
> >> Operators are sometimes
> >> spoken of as returning expressions (indeed, the Standard used to employ
> >> that turn of phrase in one or two places);
>
> > All the more reason to ignore a Standard which was written to make
> > vendors rich.
>
> Then please do so and go somewhere else and waste your weekends and
> holidays polishing your halo somewhere else.

== 4 of 4 ==
Date: Sat, Jan 9 2010 8:53 pm
From: Ben Bacarisse

spinoza1111 <spinoza1111@yahoo.com> writes:

> On Jan 10, 1:19 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> > On Jan 9, 10:33 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> >>spinoza1111<spinoza1...@yahoo.com> writes:
>> >> > On Jan 7, 11:08 am, Seebs <usenet-nos...@seebs.net> wrote:
>> >> >> On 2010-01-07, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> >> >> > ... For example, listing 10 in chapter 10 shows:
>>
>> >> >> > #define ABS(a) (a) < 0 ? -(a) : (a)
>>
>> >> >> > which might be there to show how /not/ to write a macro (please tell
>> >> >> > me it is).
>>
>> >> >> You lose.
>>
>> >> >> "When this program is compiled, a in the macro definition will be
>> >> >> substituted with the values -1 and 1. The parentheses that enclose
>> >> >> a ensure proper substitution in all cases. For example, if the
>> >> >> parentheses around a were removed, this expression:
>> >> >> ABS(10-20)
>> >> >> would be converted to
>> >> >> 10-20 < 0 ? -10-20 : 10-20
>> >> >> after macro replacement and would yield the wrong result."
>>
>> >> >> So, yeah, "all cases" meaning "all cases where the macro is not used in a
>> >> >> larger expression".
>> <snip>
>> >> Why would
>> >> someone suggest that ABS might be written that way? It will trip
>> >> every beginner up.
>>
>> > Herb should have known the rule; he probably did know the rule.
>> > However, most of his audience works in shops where rules in excess of
>> > the language are known as "standards", and in these shops, employees
>> > who cultivate their own approaches (including approaches that might be
>> > recommended by people who consider themselves hotshots) are terminated
>> > as "not part of the team". Therefore, it seems that Schildt and/or his
>> > editors decided not to include a variety of "coding standards" that
>> > have evolved because of the poor design of C.
>>
>> What logic lead him to cover one important aspect of function-like
>> macros (putting parentheses round the parameters) and exclude another
>> (parentheses round the whole expression)? It look to me like a simple
>> mistake.
>
> He didn't want to explain "my" 1990 rule (parenthesize formal
> parameters in macro definitions, decide whether to return an
> expression or a statement, return nothing else, if you return an
> expression return it in its own set of round parentheses, if you
> return a statement return the statement list in its own set of braces)
> because there might have been counter-examples and the rule is rather
> complicated.
>
> To be able to understand it, the programmer has to know the difference
> between a formal and an actual parameter and Herb could not assume
> this knowledge in his readers.

This is nonsense. It does not fit the facts: he does explain the part
you think is too complex -- what you call the actual/formal parameter
distinction. He leaves out the simple bit that would make his ABS
example usable.

He sensibly makes no mention of the statement part of your rule
because there is a better options available: the do ... while (0)
idiom.

<snip>
>> >> Code like that does not help anyone who has to deal with C in a real
>> >> job. People like that need correct examples and models of good
>> >> style. Why, for example, is he using 'gets'; C's worst function (and
>> >> an officially deprecated one) if he is just trying to help people muddle
>> >> though with this terrible language?
>>
>> > Don't blame Herb for the cowardice of C standards writers who won't
>> > get rid of bad features once and for all when this might harm the
>> > profits of vendors.
>>
>> It's gone. The next C standard will not have gets. If there is ever
>> a 5th edition, presumably the code will be corrected to remove
>> repeated use of a deprecated function (85 uses).
>
> Pray, what is gets() replaced with?

Nothing. Of course you can write it in a line or two so there is no
loss if someone wants to perpetuate the problem.

>> But that is not the point. The world is changed by education not
>> standards committees. Educators should take the lead in teaching the
>> best practise.
>
> They do. They say "don't use C, use Java".

I thought we were talking about Herbert Schildt. At least I was.
Writing four editions of a C text does not seem like a good way to say
"don't use C".

<snip>
--
Ben.

==============================================================================
TOPIC: Software Development opportunities - High Availability / Embedded /
Middleware / Linux
http://groups.google.com/group/comp.lang.c/t/e33c276101a75ac9?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 9 2010 10:38 pm
From: stephbt

GoAhead Software is the worldwide leader in standards-based high
availability solutions. The company offers high availability
middleware for carrier-grade and mission critical systems and sells
its solutions to telecom, media, and aerospace and defense equipment
manufacturers. We are currently seeking Software Developers to join
our growing team.

Description:
Responsibilities include taking an active role in the architecture,
design, implementation, and test of complex high availability
middleware in a cross-platform environment (primarily Linux).

Qualifications:
• 4+ years of experience designing, implementing complex system
software in an embedded environment (primarily Linux)
• Excellent proficiency in C with some exposure to C++
• Experience with Linux kernel (CGL preferred), GNU tool chain,
makefiles, and build tools
• Experience in a SMP multi-core environment (threading, locks,
scheduling)

A complete job description can be found at:
http://www.goahead.com/aboutus/careers.aspx#

Questions and resumes should be submitted to: Stephaniebt@GoAhead.com

==============================================================================
TOPIC: static keyword
http://groups.google.com/group/comp.lang.c/t/fe645fae79b561ac?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 9 2010 10:53 pm
From: Nobody

On Thu, 07 Jan 2010 14:56:42 -0800, eryer wrote:

> i have a question about static function...for example:
>
> file1.c
> static void foo(void);
> .....
> void foo ()
> {
> ...
> }
>
> in this example, optimizations due to static keyword at compiler time
> are performed or not?

Maybe.

Declaring the function "static" gives the compiler more scope for
optimisation, as it can determine exhaustively the contexts in which the
function may be called.

==============================================================================
TOPIC: if 'also' else statment
http://groups.google.com/group/comp.lang.c/t/92dc0e195e818a8a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 9 2010 11:01 pm
From: Nobody

On Fri, 08 Jan 2010 11:41:41 +0000, Paul wrote:

> I sometimes think it would be nice if c had an 'also' statement,
> which meant that 'if a preceeding condition was true, do this as well'.
>
> This might save some untidy work-around, or much worse, copy-
> pasting. Let me know if you have a nice neat alternative.
>
> Here's an example of reading a book on weekends, but not weekdays.
> Naturally, there could be many more things done on a weekend.
>
> P.
>
> if (Day == Saturday)
> {
> WalkInPark();
> }
> else if (Day == Sunday)
> {
> AttendChurch();
> }
> also
> {
> ReadABook();
> }
> else
> {
> GoToWork();
> }

Can you re-write that in a way which reflects how C interprets it?

I.e. starting with:

if (Day == Saturday)
{
WalkInPark();
}
else
if (Day == Sunday)
{
AttendChurch();
}

At this point, is the "also" associated with the outer "if" or the inner
"if"?

Note that C doesn't have an "else if" statement. The "else" clause can
contain any statement; this can be an "if" statement, or something else.
Even if it *is* an "if" statement, it doesn't get treated any differently
because it's an "if" statement or because it's within an "else" clause.

==============================================================================
TOPIC: how can i do ?
http://groups.google.com/group/comp.lang.c/t/2e7deee5098ae0f4?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Jan 9 2010 11:05 pm
From: wahid

• Write a program that will take an integer
number n input from the user, and then
output the value of the sum of the series
• S = 12 + 22 + 32+….. + n2

== 2 of 2 ==
Date: Sat, Jan 9 2010 11:11 pm
From: Ian Collins

wahid wrote:
> • Write a program that will take an integer
> number n input from the user, and then
> output the value of the sum of the series
> • S = 12 + 22 + 32+….. + n2

Solve the problem on paper, then convert it to code, then post your
attempt if you have problems.

Asking people to do your homework is a great way to learn absolutely
nothing and fail your exams.

--
Ian Collins

==============================================================================
TOPIC: send me the solution.
http://groups.google.com/group/comp.lang.c/t/6c55c6c30a2fbd4d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 9 2010 11:06 pm
From: wahid

• Using getch() command, write a program that
will echo user key strokes onto the screen, and
if the user presses a letter (A-Z, a-z), the
echoed character will always be a capital
letter. The program terminates when the user
presses the ESC key

• (Hint, ASCII code for ESC is 27, for 'A' is 65, and
for 'a' is 97. the values are given in decimal
notation)

==============================================================================
TOPIC: what is the solution
http://groups.google.com/group/comp.lang.c/t/7cb93cca8b35784a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Jan 9 2010 11:08 pm
From: wahid

• Write a program, that would take a number n
from user, and then output the square and
cube of first n natural numbers.

Sample Output
• Enter a number: 5
• Output for 1: square 1, cube 1
• Output for 2: square 4, cube 8
• Output for 3: square 9, cube 27
• Output for 4: square 16, cube 64
• Output for 5: square 25, cube 125

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

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

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

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

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

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

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

twitter

Saturday, January 9, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts