How to convert Infix notation to postfix notation

spinoza1111 <> writes:

> On Nov 3, 7:56Â*pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> >> Wirth would have written:
>>
>> >> Â* expr = term { ("+"|"-") term } .
<snip>
>> In Wirth's version of EBNF (note the E) . ends the production. Â*()s
>> indicate grouping and | alternation (as in most regular expression
>> syntax) and {} repetition zero or more times.
>
> Does the period in Wirth-EBNF mean "the symbol we use to represent end
> of file explicitly"?

No, it denotes the end of the grammar rule. It is meta-syntax.

<snip>
--
Ben.

Ben Bacarisse

spinoza1111 <> writes:

> On Nov 3, 3:32Â*pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> >But the more I relearn about C from experts like you, the more I
>> >wonder why this language is still in use. Perhaps it will be
>> >eradicated in 2038 as much old Cobol was eradicated to prevent Y2K,
>> >since C shall blow us all to kingdom come when its timers overflow in
>> >that year. I shall work out and not drink or smoke to see that happy
>> >day.
>>
>> Which part of the C standard do you believe links C to the year 2038?
>
> Date precision. Ever wonder why spam is dated 2038? Did the standards
> fix this problem?

I am sure you can see this does not answer the question. Chris
McDonald was asking specifically about C. You seem to think there is
a problem with C's date/time functions.

--
Ben.

Ben Bacarisse

On 2009-11-03, spinoza1111 <> wrote:
> I really wish people would qualify "clarity" and relativise it to
> their perception. Like Seebach, you use the word "clarity" here. His
> code is more to your taste: I can deal with that. But not "clearer"
> except for a reader who prefers a terse style.

This is not entirely accurate. There are measurable traits such as the
time it takes people to read code, or the reliability with which they
read it. Your version of this had a lot more fluff between the code
and the reader.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs

On 2009-11-03, spinoza1111 <> wrote:
> On Nov 3, 3:32*pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> Which part of the C standard do you believe links C to the year 2038?

> Date precision.

Uh, well, no.

> Ever wonder why spam is dated 2038? Did the standards
> fix this problem?

The standard never had this problem. Individual implementors have chosen
different ways of representing dates; it's up to them to decide which
representation they want. POSIX does specify a representation in seconds
since Jan 1 1970 UTC, but does not specify a particular limit on the size
of the object used to store that value.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs

On Nov 3, 2:39*am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-02,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > This post contains the promised C code version of the infix to Polish
> > notation convertor. When run from the command line it should execute
> > all cases used to test the C Sharp version correctly. Its string
> > handling is simpler owing to the limitations of C.
>
> Okay.

Hmm, didn't see your comments. If you contribute a bug report or good
suggestion for change, I shall incorporate it.
>
> > #include <stdio.H>
> > #include <stdlib.H>
>
> Don't capitalize the "H" -- while it may happen to work on your system,
> it means the code won't compile on others. *Even an easily-fixed compile
> error makes people likely to discount your code.

Got it. Thanks.
>
> > #define MAX_POLISH_LENGTH 100
> > int errorHandler(char *strMessage)
> > {
> > * *printf("\n%s\n", strMessage); return 0;
> > }
>
> This always returns the same value, why does it have a return value at
> all?

I do this all the time in C Sharp, because when I call the error
handler I am usually preparing to return from any caller with a
Boolean value, and my practice, in C Sharp, is to always return true
or false from any method that does not otherwise return a value. Saves
a lot of bullshit and enables optimization, in my understanding.
>
> If this is for an error message, why isn't it using stderr for its output?

Because there is no meaningful distinction anymore between stderr and
stdout, and the disctinction is legacy.
>
> The double-\n thing is a bit unusual; normally a convention is adopted
> where messages should either end with (normally) or start with (less
> often) a newline, rather than providing two. *In particular, if there are
> two consecutive error messages for some reason, this would produce a blank
> line between them.
>
Yes. I like white space.

> It would seem much more useful to implement this function using ... arguments
> and the underlying vfprintf() to allow formatted messages to be displayed..
> If I were writing a function to this effect, I'd probably do:
>
> * * * * void
> * * * * errorHandler(char *msg, ...) {
> * * * * * * * * va_list ap;
> * * * * * * * * va_start(ap, fmt);
> * * * * * * * * vfprintf(stderr, fmt, ap);
> * * * * * * * * va_end(ap);
> * * * * }
>

I don't see the worth of this at this time, but I may be missing
something.

> You prefix the variable's name with a type. *While that certainly CAN be
> a reasonable thing, it's important to ensure that the type used is a real
> abstract type, not merely a language type -- language types are already
> type checked.

Do you mean my use of Hungarian here?
>
> > int errorHandlerSyntax(int intIndex, char *strMessage)
>
> You're using Systems Hungarian here, which is crap. *Don't. *Apps Hungarian
> is what Simonyi proposed and demonstrated to be useful. *Systems Hungarian
> isn't useful, and leads to bugs later.

This is not my experience, especially with modern editors. It doesn't
cause bugs unless it is not maintained. What part of strong typing
don't you understand?

>
> > {
> > * *printf("\nError at character %d: %s\n",
> > * * * * * * * intIndex,
> > * * * * * * * strMessage);
> > * *return 0;
> > }
>
> This is a useless message. *It doesn't tell the user what the character
> IS, nor does it give the user any feedback as to the nature of the message.
> And, again, suggest that you implement format arguments.

The most recent version prints the infix expression and puts a dollar
sign under the error point, so your point is taken. The strMessage
gives the "feedback".
>
> > int stringLength(char *strInstring)
> > {
> > * *int intIndex1;
> > * *for (intIndex1 = 0;
> > * * * * * * strInstring[intIndex1] != '\0';
> > * * * * * * intIndex1++) { }
> > * *return intIndex1;
> > }
>
> Why the **** did you even write this? *

Because string.h is ****ing ****ed.

> strlen() exists for a reason.

I don't choose to include libraries unnecessarily when I can write a
little code for the limited amount of functionality that I need.

> And just for extra credit: *This name is reserved for use exclusively
> by the implementation, since it starts with "str" followed by a lowercase
> letter. *In practice it's likely harmless in modern systems because
> names are usually case-sensitive, and the standard doesn't define library
> functions with camelCase.
>
> But it's still stupid.

In your view. In my view, the "library" approach of C is horseshit
because you get a Lot Of Useless Crap for one little function that you
need.
>
> > int stringAppendChar(char *strInstring,
> > * * * * * * * * * * * * * * * * * * char chrNew,
> > * * * * * * * * * * * * * * * * * * int intMaxLength)
> > {
> > * *int intLength = stringLength(strInstring);
> > * *if (intLength >= intMaxLength - 1)
> > * *{
> > * * * * * *errorHandler
> > * * * * * * * * * *("Cannot append character: string too long");
> > * * * * * *return 0;
> > * *}
> > * *strInstring[intLength] = chrNew;
> > * *strInstring[intLength + 1] = '\0';
> > * *return -1;
> > }
>
> int
> stringAppendChar(char *s, char c, size_t max) {
> * * * * char *end = strchr(s, '\0');
> * * * * if (end - s < max) {
> * * * * * * * * *end++ = c;
> * * * * * * * * *end = '\0';
> * * * * * * * * return end - s;
> * * * * } else {
> * * * * * * * * return -1;
> * * * * }
>
> }
>
> Note that I've changed the sense of the return value. *This is because
> by convention -1 indicates a failure. *Returning the actual length,
> rather than a meaningless value, gives the caller some additional
> information.

No, -1 is the truest true value. My understanding (let me know if it's
changed since 1991), zero is falseness whereas nonzero is truthiness.
Well, -1, on twos-complement systems, which despite your nonsense in
C: The Complete Nonsense are dominant, is the number least like zero
since it's all ones and isn't that a kiss my ass?


>
> Note that I've preserved the probable-bug, which is that if you have an
> array of 15 characters, and you call this function with the limit 15 on
> an array containing 14 non-zero characters and a null byte,
> it'll write the 16th character of the 15-character array. *That's almost
> always a bad choice.

Making sure that the only string I allocate and append to, the Polish
string, is on my to do. I was worried about screwing that up, but I
malloc'd 100 bytes for the Polish string, and none of my test cases
approach that length.

The next version (not the one I posted this evening, Nov 3 in China
time) will malloc n characters for the Polish, where n is the number
of characters in the infix less the number of parentheses and blanks.
This will break the string append if I didn't do it right, and I shall
in all probability incorporate this observation.
>
> I've omitted the ridiculous error message call, for reasons which shall
> become apparent.

So it's ridiculous to give a humane error message? Explain.
>
>
>
>
>
> > int appendPolish(char *strPolish, char chrNext)
> > {
> > * *return
> > * * * * * *((*strPolish == '\0' || *strPolish == ' ')
> > * * * * * * ?
> > * * * * * * -1
> > * * * * * * :
> > * * * * * * stringAppendChar(strPolish,
> > * * * * * * * * * * * * * * *' ',
> > * * * * * * * * * * * * * * * * * * * * * * *MAX_POLISH_LENGTH))
> > * * * * &&
> > * * * * * *stringAppendChar(strPolish,
> > * * * * * * * * * * * * * * chrNext,
> > * * * * * * * * * * * * * * * * * * * * * * MAX_POLISH_LENGTH)
> > * * * * &&
> > * * * * * *stringAppendChar(strPolish, ' ', MAX_POLISH_LENGTH);
> > }
>
> This is just plain horrid. *The layout is surreal, and the logic
> opaque.

The layout is the result of tabs being converted to blanks. Tomorrow I
shall resubmit the detabbed code.
>
> I think you mean:
>
> int appendPolish(char *strPolish, char chrNext)
> {
> * if (*strPolish == ' ' || *strPolish == '\0')
> * * return -1;
> * ... wait, this doesn't even make sense.
>
> }
>
> This function aborts if the FIRST character of strPolish is a space or
> a null, but then appends characters off at the end of strPolish. *This
> makes no sense. *You'll have to put in some kind of explanatory comment
> to justify that.
>
This code has been rewritten, so your point may be correct, but it's
moot.

> There's also the fact that calling stringAppendChar three times in a row
> is stupid. *Figure out how many characters are left, and if there's enough
> room for three, append all three at once. *Appending one or two of them
> is not useful.

Point taken. The code was rewritten. Great minds think alike. You too.
>
> > int mulFactor(char *strInfix,
> > * * * * * * * * * * *char *strPolish,
> > * * * * * * * * * * *int *intPtrIndex,
> > * * * * * * * * * * *int intEnd)
> > { /* mulFactor = LETTER | NUMBER | '(' expression ')' */
> > * *int intIndexStart = 0;
> > * *int intLevel = 0;
> > * *char chrNext = ' ';
> > * *int intInner;
> > * *if (*intPtrIndex > intEnd)
> > * * * * * *return errorHandlerSyntax(*intPtrIndex,
> > * * * * * * * * * * * * * * * * * * *"mulFactor unavailable");
>
> This is a crappy error message. *The problem has nothing at all to do with
> mulFactor. *It has to do with you having, apparently, run out of room
> or something. *So say so; give a message like "string too long".

Study the code a little more thoroughly. While this particular test
may have changed in my Nov 3 version, it was necessary in this version
because mulFactor in all versions must needs incorporate the functions
of a scanner (including testing end of input). If input has been
exhausted, we have entered mulFactor expecting a multiply factor and
there is none.
>
> > * *if (chrNext == '(')
>
> This is the point where you should be calling a different function that
> handles parenthesized expressions, IMHO.
>
> > * * * * * *if (!expression(strInfix,
> > * * * * * * * * * * * * * * * *strPolish,
> > * * * * * * * * * * * * * * * * * * * * * *&intInner,
> > * * * * * * * * * * * * * * * * * * * * * **intPtrIndex - 2))
>
> Ugh.
>
> Seems like this would be a great time to refactor this more sanely. *In
> particular, you're having the higher-level code (mulfactor) try to guess
> the range of the substring.

Yes, I said it looks ahead.
If it didn't it would be dead.

In this code, mulFactor integrates scanning and parsing and is
lowlevel. As I have said elsewhere, it might be better to avoid this
lookahead by making "end of input" a grammar category, but this "ugly"
code is elegant in context, since I wanted to keep the program short;
it seemed overkill to write a lexical scanner for mulFactor to call.
>
> What happens when someone asks you to support strings? *

At that point, I factor. Premature factorization especially for you
bums is in my experience a waste of time.

> Then suddenly
> mulfactor() has to be smart enough to find the end of:
> * * * * (a + ")")
>
> and you're making a ton of work. *Wrong. *When you see the (, pass it off
> to the function which tries to find an expression followed by a trailing ),
> and have the expression parser hand what it found so far back up when it
> sees the ) -- at which point the parens function finds its trailing ) and is
> happy.

"The function which tries to find an expression followed by a
trailing )"? Give me a break. That's not a grammar category and
writing such a function is asking for trouble.

It's not necessarily ugly to "read ahead": cf the 2nd ed. of the
Dragon Book, p 78. Also, see Nilges' "Build Your Own Goddamn .Net
Language and Goddamn Compiler" for a discussion of the need for
lookahead in processing unary minus and right parentheses. I worked
through these issues several years ago in VB, and if you care to
comment on my approaches, buy my book. Of course, if you do a hatchet
job on the book, I'll be on your case like a fly on ****...save where
you are right in any important way, in which case I will help you
write your critique and get your errata into Apress' Web site.

Reading ahead steps outside the formal grammar paradigm, but think of
it as having an "oracle": this metaphor was used in an old MacDonald
Elsevier "Monograph in Computer Science": the one, in fact, on
compiler development. It's like using a lex symbol to represent end of
input.

>
> > char *infix2Polish(char *strInfix)
> > {
> > * *int intIndex = 0;
> > * *char *strPolish = malloc(MAX_POLISH_LENGTH);
>
> Sure enough, you did what I thought you'd do. *You allocate MAX_POLISH_LENGTH
> characters, but then, you use MAX_POLISH_LENGTH as the cap you pass to
> strAppendChar, meaning that if your Polish string contains MAX_POLISH_LENGTH-1
> characters, you will end up writing one past the end of the array.

Point taken. I was suspicious of the code myself since I have
encountered that problem before. It's an artifact of the unsafe design
of the Infantile Disorder in which I am coding. My plan was to address
it when I got around to doing an EXACT malloc of n bytes, where n is
the number of nonparentheses and nonblanks in the infix string plus
one for the Stupid Nul Byte.

>
> It turns out that the fencepost conventions people use in C are there for
> a good reason.
>
> > * *if (strPolish == 0)
> > * * * * * *errorHandler("Can't get storage");
> > * *strPolish[0] = '\0';
>
> Since errorHandler doesn't exit in any way, you're still going to segfault
> (or whatever) when you reach this line.

Thanks for pointing this out. Probably should return.
>
> > * *if (!expression(strInfix,
> > * * * * * * * * * * * *strPolish,
> > * * * * * * * * * * * * * * * * * *&intIndex,
> > * * * * * * * * * * * * * * * * * *stringLength(strInfix) - 1))
> > * *{
> > * * * * * *errorHandler("Can't parse expression");
> > * * * * * *return "";
>
> Oh, that's great. *You are now returning pointers from this function which
> MAY OR MAY NOT be the results of malloc(), so you can't free them safely.

Very good point.
>
> This should be:
> * * * * strPolish[0] = '\0';
> * * * * return strPolish;
>
Excellent. You should turn pro.

> > * *printf("Expect 10 113 + a *: %s\n",
> > * * * * * * * infix2Polish("(10+113)*a"));
>
> Because infix2Polish allocates memory, but you never free the results, this
> is a memory leak.

Don't be a silly bastard. It's not a memory leak since I return to main
() (I was tempted to return void just to **** you off but Microsoft C
sets me up with int main()). Now you're making silly comments just to
pad your anti-resume. Shape up.

Nonetheless, I like the idea of having a free for every malloc, since
there's this cool computer author that recommends doing this, and it
makes eminent sense.

{Chortle)

Therefore I shall fix this.

>
> > int main(int intArgCount, char **strArgs)
>
> Renaming the args to main, not useful. *Declaring them when you're not using
> them, also not useful.

I prefer that all things use my naming style, thank you. And they are
for later use.

>
> > {
> > * * tester();
> > * * return;
>
> return without a value in function not returning void
>
> Okay, I will concede one point: *You would actually be better off reading
> Schildt's books than muddling along without. *You'd be even better off reading
> a better C book, but really, any port in a storm.

Bite my crank.

But thanks for your observations. Not as good as Bacarisse but at
least you jumped in and got to work, unlike your friend Heathfield,
who's trashed so many people that he's afraid to make a mistake.

Furthermore, thanks to your help and my own coding and testing, I am
ramping back up quickly in C and shall shortly, if I persist, run
rings around you. This is because Princeton was right when they
refused to conduct classes at uni level in C, and had a mere Roosevelt
graduate (me) teach C. A programming language is easy to learn: it's
the science and effective style that's difficult...the latter so much
so, that most programmers' opinions on style are worthless (your views
on Hungarian being an example).

However, C is also a waste of spirit in an expense of shame. I am also
an artist and a teacher, and instead of focusing on nonsense problems
that wouldn't exist if C had been designed not misbegotten I could be
preparing classes or painting pictures. Instead I am muttering over
runes from the Dark Ages and the process is making me crabby. I am
having to restrain myself from kicking small animals.

Nonetheless I shall persist for now, in order to demonstrate that two
propositions are true. One is that I'm smarter than you. The other is
that we can work together to find bugs in each others' code because
nobody is too smart to make stupid mistakes, a lesson which if you
learn well will, I hope, cause you to withdraw The Vicious Tirade.

>
> -s
> --
> Copyright 2009, all wrongs reversed. *Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!- Hide quoted text -
>
> - Show quoted text -

spinoza1111

On 2009-11-03, spinoza1111 <> wrote:
> On Nov 3, 2:39*am, Seebs <usenet-nos...@seebs.net> wrote:

> I do this all the time in C Sharp, because when I call the error
> handler I am usually preparing to return from any caller with a
> Boolean value, and my practice, in C Sharp, is to always return true
> or false from any method that does not otherwise return a value. Saves
> a lot of bullshit and enables optimization, in my understanding.

Be interesting to know how it "enables optimization".

>> If this is for an error message, why isn't it using stderr for its output?

> Because there is no meaningful distinction anymore between stderr and
> stdout, and the disctinction is legacy.

Simply untrue -- there's a ton of systems out there which maintain the
distinction clearly. Again, if you're posting code that might some day
be used or tried by other people, doing things right matters even if it
doesn't have a discernable effect on your system. There is a difference
there, even if it doesn't affect your personal desktop.

>> The double-\n thing is a bit unusual; normally a convention is adopted
>> where messages should either end with (normally) or start with (less
>> often) a newline, rather than providing two. *In particular, if there are
>> two consecutive error messages for some reason, this would produce a blank
>> line between them.

> Yes. I like white space.

Blank lines used for emphasis are useful, blank lines which flood the display
with blank lines just disrupt the reader's flow.

>> It would seem much more useful to implement this function using ... arguments
>> and the underlying vfprintf() to allow formatted messages to be displayed.
>> If I were writing a function to this effect, I'd probably do:

> I don't see the worth of this at this time, but I may be missing
> something.

Consider the option of writing messages like:

errorHandler("syntax error: Got '%c', was expecting an operator.", s[i]);

Basically, anything that makes it convenient and easy to give more
specific feedback.

>> You prefix the variable's name with a type. *While that certainly CAN be
>> a reasonable thing, it's important to ensure that the type used is a real
>> abstract type, not merely a language type -- language types are already
>> type checked.

> Do you mean my use of Hungarian here?

There are two kinds of Hungarian. The kind that is actually in some way
beneficial, which denotes abstract types, and the kind which denotes compiler
types and is demonstrably harmful. You used the latter kind.

>> You're using Systems Hungarian here, which is crap. *Don't. *Apps Hungarian
>> is what Simonyi proposed and demonstrated to be useful. *Systems Hungarian
>> isn't useful, and leads to bugs later.

> This is not my experience, especially with modern editors. It doesn't
> cause bugs unless it is not maintained. What part of strong typing
> don't you understand?

I understand strong typing just fine. That's why systems hungarian is stupid;
it's not actually adding any data.

Apps Hungarian would be to, say, indicate whether something is a distance
or an index or whatever -- all things which could be stored in an int,
but which are not interchangeable sorts. Systems Hungarian is useless,
because it just replicates stuff the compiler can already check.

Interestingly, Simonyi has come out pretty strongly against the Systems
Hungarian thing -- and given that he's the originator of Hungarian notation,
I thin kthat's pretty damning.

> Because string.h is ****ing ****ed.

No, it isn't.

>> strlen() exists for a reason.

> I don't choose to include libraries unnecessarily when I can write a
> little code for the limited amount of functionality that I need.

When the library is part of the core language, that attitude is stupid.
You can't outperform the library writers, and every line of code you
spend reinventing the wheel is wasted.

> In your view. In my view, the "library" approach of C is horseshit
> because you get a Lot Of Useless Crap for one little function that you
> need.

Maybe, except *you already got it*. You've already paid the cost, might as
well use the stuff.

> No, -1 is the truest true value.

It may be, but it's also used widely as an out-of-band error indicator.

> My understanding (let me know if it's
> changed since 1991), zero is falseness whereas nonzero is truthiness.
> Well, -1, on twos-complement systems, which despite your nonsense in
> C: The Complete Nonsense are dominant, is the number least like zero
> since it's all ones and isn't that a kiss my ass?

Actually, it's not, because no one cares about the bit representation; we
just care whether the number it represents communicates clearly to the
user.

>> Note that I've preserved the probable-bug, which is that if you have an
>> array of 15 characters, and you call this function with the limit 15 on
>> an array containing 14 non-zero characters and a null byte,
>> it'll write the 16th character of the 15-character array. *That's almost
>> always a bad choice.

> Making sure that the only string I allocate and append to, the Polish
> string, is on my to do. I was worried about screwing that up, but I
> malloc'd 100 bytes for the Polish string, and none of my test cases
> approach that length.

Which is to say, it does indeed turn out that you got it wrong.

This is the other reason to use the library -- the library functions
handle their boundaries correctly, in general.

>> I've omitted the ridiculous error message call, for reasons which shall
>> become apparent.

> So it's ridiculous to give a humane error message? Explain.

It's not a useful message in context.

> Study the code a little more thoroughly. While this particular test
> may have changed in my Nov 3 version, it was necessary in this version
> because mulFactor in all versions must needs incorporate the functions
> of a scanner (including testing end of input). If input has been
> exhausted, we have entered mulFactor expecting a multiply factor and
> there is none.

But the user doesn't care about "mulFactor". The user wants to know
"we reached the end of the string while expecting more input". The internal
details like "mulFactor" are not part of the user's knowledge of what
the program is doing, and shouldn't have to be.

>> Seems like this would be a great time to refactor this more sanely. *In
>> particular, you're having the higher-level code (mulfactor) try to guess
>> the range of the substring.

> Yes, I said it looks ahead.
> If it didn't it would be dead.

Looking ahead like that, though, means that that function has to handle
all sorts of hypothetical future special cases -- which is silly. Just
have the parser recurse and tell you how far it got.

> At that point, I factor. Premature factorization especially for you
> bums is in my experience a waste of time.

I'm a big fan of handling at least the common cases up front.

> It's not necessarily ugly to "read ahead": cf the 2nd ed. of the
> Dragon Book, p 78. Also, see Nilges' "Build Your Own Goddamn .Net
> Language and Goddamn Compiler" for a discussion of the need for
> lookahead in processing unary minus and right parentheses. I worked
> through these issues several years ago in VB, and if you care to
> comment on my approaches, buy my book. Of course, if you do a hatchet
> job on the book, I'll be on your case like a fly on ****...save where
> you are right in any important way, in which case I will help you
> write your critique and get your errata into Apress' Web site.

You need some lookahead, but a single token of lookahead should do for
most of the stuff we care about. Scanning through the string of characters
is a bad way to do lookahead.

> Point taken. I was suspicious of the code myself since I have
> encountered that problem before. It's an artifact of the unsafe design
> of the Infantile Disorder in which I am coding.

Except it's not. It's easy to get right, and thousands of people do.
You just have to be aware of it.

>> This should be:
>> * * * * strPolish[0] = '\0';
>> * * * * return strPolish;

> Excellent. You should turn pro.



> Don't be a silly bastard. It's not a memory leak since I return to main
> () (I was tempted to return void just to **** you off but Microsoft C
> sets me up with int main()). Now you're making silly comments just to
> pad your anti-resume. Shape up.

There is a historical quirk, likely no longer relevant: On some DOS/Windows
implementations, long ago, failing to free malloc'd memory before exiting
resulted in the memory being lost until the next reboot.

> But thanks for your observations. Not as good as Bacarisse but at
> least you jumped in and got to work, unlike your friend Heathfield,
> who's trashed so many people that he's afraid to make a mistake.

Heathfield is not afraid to make mistakes, he just doesn't very often.
He was making a point -- which is that if you want people reviewing code,
running it through a picky compiler is a great starting point.

> Furthermore, thanks to your help and my own coding and testing, I am
> ramping back up quickly in C and shall shortly, if I persist, run
> rings around you.

Good luck with that.

> Nonetheless I shall persist for now, in order to demonstrate that two
> propositions are true. One is that I'm smarter than you.

I doubt it. It's not theoretically impossible, but it would certainly
surprise me.

> The other is
> that we can work together to find bugs in each others' code because
> nobody is too smart to make stupid mistakes, a lesson which if you
> learn well will, I hope, cause you to withdraw The Vicious Tirade.

Not really. People do, indeed, make stupid mistakes. The question is
whether they then try to correct them...

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs

Seebs <usenet-> writes:
> On 2009-11-03, spinoza1111 <> wrote:
>> On Nov 3, 3:32Â*pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>>> spinoza1111<spinoza1...@yahoo.com> writes:
>>> Which part of the C standard do you believe links C to the year 2038?
>
>> Date precision.
>
> Uh, well, no.
>
>> Ever wonder why spam is dated 2038? Did the standards
>> fix this problem?
>
> The standard never had this problem. Individual implementors have chosen
> different ways of representing dates; it's up to them to decide which
> representation they want. POSIX does specify a representation in seconds
> since Jan 1 1970 UTC, but does not specify a particular limit on the size
> of the object used to store that value.

All correct.

On the other hand, if I understand the history correctly, the first
implementations to provide time_t defined it as a signed 32-bit
integer type measuring seconds since 1970-01-01. The standard
came along later and established looser requirements that were
consistent with the existing implementations, but also allowed for
other representations (such as using a 64-bit integer, choosing an
epoch other than 1970-01-01, choosing a resolution other than one
second, and so forth). The POSIX requirements are tighter than
the ISO C requirements, but they still allow for 64-bit integers.
(And I suspect there were a few 64-bit time_t implementations before
either standard came along.)

The standards didn't fix the problem, but they certainly allowed
for it to be fixed.

--
Keith Thompson (The_Other_Keith) kst- <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"

Keith Thompson

spinoza1111 <> writes:

>On Nov 3, 3:32=A0pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> >But the more I relearn about C from experts like you, the more I
>> >wonder why this language is still in use. Perhaps it will be
>> >eradicated in 2038 as much old Cobol was eradicated to prevent Y2K,
>> >since C shall blow us all to kingdom come when its timers overflow in
>> >that year. I shall work out and not drink or smoke to see that happy
>> >day.
>>
>> Which part of the C standard do you believe links C to the year 2038?

>Date precision. Ever wonder why spam is dated 2038? Did the standards
>fix this problem?


You've missed the point (again); answered in other people's replies.

Standards permit those evil blooksucking compiler and library
developers to avoid the problem.

--
Chris.

Chris McDonald

On Nov 4, 2:18*am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-03,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > On Nov 3, 2:39*am, Seebs <usenet-nos...@seebs.net> wrote:
> > I do this all the time in C Sharp, because when I call the error
> > handler I am usually preparing to return from any caller with a
> > Boolean value, and my practice, in C Sharp, is to always return true
> > or false from any method that does not otherwise return a value. Saves
> > a lot of bullshit and enables optimization, in my understanding.
>
> Be interesting to know how it "enables optimization".

Bone up on compiler optimization and tail recursion. I'm not gonna
explain it to you. Do you own Sethi Aho et al 2nd ed.?
>
> >> If this is for an error message, why isn't it using stderr for its output?
> > Because there is no meaningful distinction anymore between stderr and
> > stdout, and the disctinction is legacy.
>
> Simply untrue -- there's a ton of systems out there which maintain the
> distinction clearly. *Again, if you're posting code that might some day
> be used or tried by other people, doing things right matters even if it
> doesn't have a discernable effect on your system. *There is a difference
> there, even if it doesn't affect your personal desktop.

Don't even presume to lecture me, kiddo. Your consideration for others
is on display in your treatment of Schildt.
>
> >> The double-\n thing is a bit unusual; normally a convention is adopted
> >> where messages should either end with (normally) or start with (less
> >> often) a newline, rather than providing two. *In particular, if there are
> >> two consecutive error messages for some reason, this would produce a blank
> >> line between them.
> > Yes. I like white space.
>
> Blank lines used for emphasis are useful, blank lines which flood the display
> with blank lines just disrupt the reader's flow.

You have a disturbing tendency to lapse into sloppy English and
corporatese whenever you want to stop thinking, and when this harms
other people, it needs to stop. What on earth is "the reader's flow?"
Menstrual?
>
> >> It would seem much more useful to implement this function using ... arguments
> >> and the underlying vfprintf() to allow formatted messages to be displayed.
> >> If I were writing a function to this effect, I'd probably do:
> > I don't see the worth of this at this time, but I may be missing
> > something.
>
> Consider the option of writing messages like:
>
> * errorHandler("syntax error: Got '%c', was expecting an operator.", s[i]);
>
> Basically, anything that makes it convenient and easy to give more
> specific feedback.

Haven't you run the latest edition? It does this visually on any
monospace window by putting a dollar sign under the point at which the
error is discovered...although now that I think of it, it's probably a
mistake on my part to assume monospace output.

I don't think, however, that it makes sense to overengineer this
issue, in part because what rilly needs change is the fact that
recursive descent implemented simply produces too many "nested" error
messages and is bad at error recovery.
>
> >> You prefix the variable's name with a type. *While that certainly CAN be
> >> a reasonable thing, it's important to ensure that the type used is a real
> >> abstract type, not merely a language type -- language types are already
> >> type checked.
> > Do you mean my use of Hungarian here?
>
> There are two kinds of Hungarian. *The kind that is actually in some way
> beneficial, which denotes abstract types, and the kind which denotes compiler
> types and is demonstrably harmful. *You used the latter kind.
>
> >> You're using Systems Hungarian here, which is crap. *Don't. *Apps Hungarian
> >> is what Simonyi proposed and demonstrated to be useful. *Systems Hungarian
> >> isn't useful, and leads to bugs later.
> > This is not my experience, especially with modern editors. It doesn't
> > cause bugs unless it is not maintained. What part of strong typing
> > don't you understand?
>
> I understand strong typing just fine. *That's why systems hungarian is stupid;
> it's not actually adding any data.

No, it's organizing material for easy retrieval in a modern editor
with intellisense.


>
> Apps Hungarian would be to, say, indicate whether something is a distance
> or an index or whatever -- all things which could be stored in an int,
> but which are not interchangeable sorts. *Systems Hungarian is useless,
> because it just replicates stuff the compiler can already check.
>
> Interestingly, Simonyi has come out pretty strongly against the Systems
> Hungarian thing -- and given that he's the originator of Hungarian notation,
> I thin kthat's pretty damning.
>

He's not the originator. "Systems Hungarian" was already in use in IBM
when he was still in Hungary helping to destroy socialism as a punk
kid who needed a kick in the ass. It is in fact mentioned in a book by
Richard Diebold published in 1962.

> > Because string.h is ****ing ****ed.
>
> No, it isn't.
>
> >> strlen() exists for a reason.
> > I don't choose to include libraries unnecessarily when I can write a
> > little code for the limited amount of functionality that I need.
>
> When the library is part of the core language, that attitude is stupid.
> You can't outperform the library writers, and every line of code you
> spend reinventing the wheel is wasted.

Actually, for trivial algorithms, I can.

>
> > In your view. In my view, the "library" approach of C is horseshit
> > because you get a Lot Of Useless Crap for one little function that you
> > need.
>
> Maybe, except *you already got it*. *You've already paid the cost, might as
> well use the stuff.

I didn't pay a dime for Microsoft C++ Express.
>
> > No, -1 is the truest true value.
>
> It may be, but it's also used widely as an out-of-band error indicator.

Yes. The confusion is here created not by me, however, but by C's lack
of a boolean type.
>
> > My understanding (let me know if it's
> > changed since 1991), zero is falseness whereas nonzero is truthiness.
> > Well, -1, on twos-complement systems, which despite your nonsense in
> > C: The Complete Nonsense are dominant, is the number least like zero
> > since it's all ones and isn't that a kiss my ass?
>
> Actually, it's not, because no one cares about the bit representation; we
> just care whether the number it represents communicates clearly to the
> user.

This is childish. "I care about all sorts of useless **** like what
main() returns but not about interpersonal decency, nor elegance I
didn't invent". You see, C lacks Boolean values, and -1 is more
visible than 1: more readable: more elegant, and, in a twos complement
system, it uses the literary technique of "evocation", for it evokes
in the intelligent code reader a vision of all ones (and it's more
visible at what we used to call core dump time, and what is now The
Time of Blue Screen of Death). Useful beauty. In your comments

Nonsense prevails, modesty fails: all this useless beauty (Elvis
Costello)
>
> >> Note that I've preserved the probable-bug, which is that if you have an
> >> array of 15 characters, and you call this function with the limit 15 on
> >> an array containing 14 non-zero characters and a null byte,
> >> it'll write the 16th character of the 15-character array. *That's almost
> >> always a bad choice.
> > Making sure that the only string I allocate and append to, the Polish
> > string, is on my to do. I was worried about screwing that up, but I
> > malloc'd 100 bytes for the Polish string, and none of my test cases
> > approach that length.
>
> Which is to say, it does indeed turn out that you got it wrong.

Not in any substantive way. My goal was to get something coded and see
how you behave in a structured walkthrough where owing to the written
nature of the medium, we can exclude noncontributing thugs like
Heathfield. Right now, I am not impressed, but I think you have
potential that Heathfield lacks.


>
> This is the other reason to use the library -- the library functions
> handle their boundaries correctly, in general.
>
> >> I've omitted the ridiculous error message call, for reasons which shall
> >> become apparent.
> > So it's ridiculous to give a humane error message? Explain.
>
> It's not a useful message in context.

Words, my lord: words words words. But that's not the problem. "In
context" is meaningless corporatese.
>
> > Study the code a little more thoroughly. While this particular test
> > may have changed in my Nov 3 version, it was necessary in this version
> > because mulFactor in all versions must needs incorporate the functions
> > of a scanner (including testing end of input). If input has been
> > exhausted, we have entered mulFactor expecting a multiply factor and
> > there is none.
>
> But the user doesn't care about "mulFactor". *The user wants to know

The "user" (sigh). Sloppy English: because in a structured walkthrough
users have no place, no more than managers. You invoke "the user" as a
deus ex machina: a Lacanian phallus. But literally, that's the person
who as you say needs to be innocent of the details!

> "we reached the end of the string while expecting more input". *The internal
> details like "mulFactor" are not part of the user's knowledge of what

If you'd learn how to write properly, which you can't, you'd here
express this as an assertion which should always be true. My program
satisfies that assertion. Rather than quarreling about whether some
"user" (some abstract thug with money and a loud mouth) can see it, I
need to use informal or formal argumentation to prove that "there is
no input, that is not completely examined by my code, such that each
byte is scanned" (X strong) or "there is no valid input where this is
untrue" (weak X: implied by strong X).

I will provide a short informal argument to this effect in comments, a
fix to the library case problem, a new malloc scheme that will avoid
the probable bug you found, and detabbed properly formatted source by
Tue eve China time. I believe these are the only real problems you
found (that weren't corrected in the latest version I posted), and
once again as in the case of Schildt you have a disturbing tendency to
pad your attacks with opinion and trivia.

> the program is doing, and shouldn't have to be.
>
> >> Seems like this would be a great time to refactor this more sanely. *In
> >> particular, you're having the higher-level code (mulfactor) try to guess
> >> the range of the substring.
> > Yes, I said it looks ahead.
> > If it didn't it would be dead.
>
> Looking ahead like that, though, means that that function has to handle
> all sorts of hypothetical future special cases -- which is silly. *Just
> have the parser recurse and tell you how far it got.

Nonsense. It looks ahead for one reason alone. Again, on the related
issue of one-character lookahead cf Aho/Sethi et al. 2nd ed. p 78.
Drop the issue, you're just making a big deal out of it to show off.
>
> > At that point, I factor. Premature factorization especially for you
> > bums is in my experience a waste of time.
>
> I'm a big fan of handling at least the common cases up front.
>
> > It's not necessarily ugly to "read ahead": cf the 2nd ed. of the
> > Dragon Book, p 78. Also, see Nilges' "Build Your Own Goddamn .Net
> > Language and Goddamn Compiler" for a discussion of the need for
> > lookahead in processing unary minus and right parentheses. I worked
> > through these issues several years ago in VB, and if you care to
> > comment on my approaches, buy my book. Of course, if you do a hatchet
> > job on the book, I'll be on your case like a fly on ****...save where
> > you are right in any important way, in which case I will help you
> > write your critique and get your errata into Apress' Web site.
>
> You need some lookahead, but a single token of lookahead should do for
> most of the stuff we care about. *Scanning through the string of characters
> is a bad way to do lookahead.

Says who? I refer you to Nilges 2004. He recommends it.

Seriously, saying dully "ooo dat is a bad way to do wookahead" doesn't
make what you say true. Stick to what you're good at, which strangely
is C, not programming.
>
> > Point taken. I was suspicious of the code myself since I have
> > encountered that problem before. It's an artifact of the unsafe design
> > of the Infantile Disorder in which I am coding.
>
> Except it's not. *It's easy to get right, and thousands of people do.
> You just have to be aware of it.
>
> >> This should be:
> >> * * * * strPolish[0] = '\0';
> >> * * * * return strPolish;
> > Excellent. You should turn pro.
>
>
>
> > Don't be a silly bastard. It's not a memory leak since I return to main
> > () (I was tempted to return void just to **** you off but Microsoft C
> > sets me up with int main()). Now you're making silly comments just to
> > pad your anti-resume. Shape up.
>
> There is a historical quirk, likely no longer relevant: *On some DOS/Windows
> implementations, long ago, failing to free malloc'd memory before exiting
> resulted in the memory being lost until the next reboot.

Fascinating. But useless.
>
> > But thanks for your observations. Not as good as Bacarisse but at
> > least you jumped in and got to work, unlike your friend Heathfield,
> > who's trashed so many people that he's afraid to make a mistake.
>
> Heathfield is not afraid to make mistakes, he just doesn't very often.

That's because he doesn't code. He in fact here emulates the very
worst sort of manager who sits back and destroys people in meetings
for taking risks, proposing solutions, and coding. He makes me sick,
and I want him out of here.

> He was making a point -- which is that if you want people reviewing code,
> running it through a picky compiler is a great starting point.
>
> > Furthermore, thanks to your help and my own coding and testing, I am
> > ramping back up quickly in C and shall shortly, if I persist, run
> > rings around you.
>
> Good luck with that.
>
> > Nonetheless I shall persist for now, in order to demonstrate that two
> > propositions are true. One is that I'm smarter than you.
>
> I doubt it. *It's not theoretically impossible, but it would certainly
> surprise me.
>
> > The other is
> > that we can work together to find bugs in each others' code because
> > nobody is too smart to make stupid mistakes, a lesson which if you
> > learn well will, I hope, cause you to withdraw The Vicious Tirade.
>
> Not really. *People do, indeed, make stupid mistakes. *The question is
> whether they then try to correct them...

I don't know what you mean. Where I agree it's a stupid mistake, I
don't "try" to correct it, I just correct it. Your corporatese on the
other hand implies that the person being objectified by the language
will recognize something with the ugly name of a "behavior pattern"
which they will then, in the debased language of Human Resources, "try
to correct", where the expectation, of course, is that he or she
(having been found wanting in a secret Calvinism: a society haunted by
predestination) will fail but "we" will have done our best.

I am here, however, for your insights on code, not for any wisdom I
see in you.

>
> -s
> --
> Copyright 2009, all wrongs reversed. *Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

spinoza1111

On Nov 4, 1:56*am, Richard Heathfield <r...@see.sig.invalid> wrote:
> In
> <cfebc09f-0b34-4de8-ab71-f309369ff...@w37g2000prg.googlegroups.com>,
>
> spinoza1111wrote:
> > On Nov 3, 2:39 am, Seebs <usenet-nos...@seebs.net> wrote:
> > > On 2009-11-02,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> <polite stuff reluctantly snipped despite its rarity value>

It's rare because when people make genuine technical remarks I respond
professionally.

Few genuine technical remarks are made here. Ben Bacarisse is by far
the best source of solid technical feedback. Seebach is just barely
acceptable since unlike Ben he doesn't organize his thoughts well and
proceeds sequentially just identifying nits. You're not even in the
running and you need to leave this discussion.

>
> >> > #define MAX_POLISH_LENGTH 100
> >> > int errorHandler(char *strMessage)
> >> > {
> >> > printf("\n%s\n", strMessage); return 0;
> >> > }
>
> >> This always returns the same value, why does it have a return value
> >> at all?
>
> > I do this all the time in C Sharp, because when I call the error
> > handler I am usually preparing to return from any caller with a
> > Boolean value, and my practice, in C Sharp, is to always return true
> > or false from any method that does not otherwise return a value.
>
> This is (close to) my practice too - in general, my functions return
> int (and the ones that don't, tend to return either void or a T* for
> some type T). Sometimes, I have no better value to return than 0
> during the development process, so return 0; goes in, awaiting more
> rigorous error handling later. Sometimes that error handling turns
> out to be unnecessary for the time being, but the return 0 stays in
> anyway, in case at some point in the future it becomes necessary to
> add error handling.
>
> <didn't read the rest - no time>
>
> --
> 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

spinoza1111