12 May
2005
12 May
'05
1:37 p.m.
Hi
I'd suspect that most didn't like the goto
because it becomes hard to implement in a structured
language. Things like random nesting of subroutines and
then goto's to various points can make things really
messed up. There are also the problems of allocated
memory. Do you keep it or clean it?
Forth, like many languages doesn't specifically have
a goto but in to Forth philosophy, you can always
write your own. Most newer Forths have an error handling
method called catch and throw. This tidies up the
stacks and still allows one to goto an outer level
of hierarchy at random depths, like a goto should.
It doesn't work at all to go to a deeper level of
hierarchy. I think this is where BASIC gets it self
into trouble.
Many think of goto as being similar to jmp in assembly.
Actually in a high level language, it is more complicated
than that. The language tend to lead one to think they
can use it just anywhere. In assembly, you are more
conscious ( or should be ) of thing like stack depth
and allocated space, since you explicitly handle these
things.
Dwight
12 May
12 May
2:32 p.m.
Actually I like exception handling even less than C-style goto; when
an exception comes, in the middle of any routine you jump scope
practically at/to a random point or circumstance and start executing
code in a sequence that the programmer couldn't really have intended.
It violates the designed control flow and is therefore evil. At least
a C-style goto scope is limited to a single subroutine. Exceptions
actually jump scope between routines. What are they thinking???
No, I prefer to get status codes and write explicit error handlers
where they make sense. Now true exceptions like a divide-by-zero,
well, I can see having exception handlers for that. But for the modern
usage of sending error codes? Horrible.
I do use goto in specific, limited ways. For example, to enter a loop
just after the top (useful in printing comma separated lists, for
example without use of a flag variable), or common exit/cleanup
handlers.
All computer scientists have ever proved is that you could get by
without goto. They jumped to an unwarranted conclusion when they
decided it should never be used.
-- John.
5:07 p.m.
John Hogerhuis wrote:
All computer scientists have ever proved is that you
could get
by without goto. They jumped to an unwarranted conclusion when
they decided it should never be used.
One of Dijkstra's interests was formal specification and verification:
basically unambigously describing what you want to do and then proving
afterwards that you've done it. You'll notice that the bit in the
middle doesn't get a look in :-) In fact, you could argue that the
bit in the middle needs to be constrained just so the proof is a
practical proposition.
So it's nothing to do with stifling your creativity: be as
creative as you like. It's just unlikely that any of us
(including you) will ever know whether your prorams (or at
least any of them of significant size) are correct or not.
Antonio
--
---------------
Antonio Carlini arcarlini at iee.org
5:28 p.m.
On 5/12/05, Antonio Carlini <a.carlini at ntlworld.com> wrote:
John Hogerhuis wrote:
Yeah there can be no algorithm to test algorithm correctness. Halting
problem... so naturally you would have to restrict yourself to
something less than a turing machine to get this.
All computer scientists have ever proved is that
you could get
by without goto. They jumped to an unwarranted conclusion when
they decided it should never be used.
One of Dijkstra's interests was formal specification and verification:
basically unambigously describing what you want to do and then proving
afterwards that you've done it. You'll notice that the bit in the
middle doesn't get a look in :-) In fact, you could argue that the
bit in the middle needs to be constrained just so the proof is a
practical proposition.
So it's nothing to do with stifling your
creativity: be as
creative as you like. It's just unlikely that any of us
(including you) will ever know whether your prorams (or at
least any of them of significant size) are correct or not.
Agreed, but nor should anyone really care about provable correctness,
right? Engineering is about making things that are practically useful,
i.e. "good enough"-- we're not designing stained glass windows for the
Church of Reason, we're simply making and maintaining tools to solve
todays problems more efficiently than if those tools were not
available.
-- John.
6:50 p.m.
John Hogerhuis wrote:
Agreed, but nor should anyone really care about
provable
correctness, right? Engineering is about making things that
are practically useful, i.e. "good enough"-- we're not
designing stained glass windows for the Church of Reason,
we're simply making and maintaining tools to solve todays
problems more efficiently than if those tools were not
available.
Certainly we should not immediately drop our coding sticks
and not touch them again until we _know_ we have attained
perfection. But I disagree strongly that we should not strive
to reach that goal.
If we had a mechanism now to create provably correct
programs (that met specifications that we could be
sure meant what we intended them to mean) - and
further assuming that use of such a mechanism did
not impose excessive cost or efficiency burdens etc, -
then I think we would have to use them for all
serious programs.
Given the choice, I'd prefer the programs I use to
work perfectly rather than imperfectly - and I'd prefer
to spend the time I program at work creating correct
code rather than being dragged back to fix yesterday's
mistake.
I'm more than willing to trade an occasional goto for that!
Antonio
--
---------------
Antonio Carlini arcarlini at iee.org
7:16 p.m.
From: "Antonio Carlini" <a.carlini at ntlworld.com>
Sent: Thursday, May 12, 2005 5:50 PM
John Hogerhuis wrote:
One big problem with goto comes from Fortran, with FORTRAN and early Basic's
the goto uses line numbers. Newer languages allow better labels:
go to 4000
Doesn't tell you much.
C
C Cleanup files and exit
C
go to 4000
This at least tells you something.
Another problem is that many programmers don't understand the compilers they
are using. If you don't understand how the compiler handles stacks etc then
we know where the problem is: It is the Programmers fault for using a tool
that they don't understand.
It is a problem with the Programmers not the tools. It reminds me of
stopping to help someone with a flat tire:
It was a young guy with a new car with his girlfriend. He had a scissor
jack that he had just shoved under the car and jacked it up. He had it
under the passenger side floor board and it punched through. Someone else
had stopped and lent him an old-fashioned bumper-jack. It had ripped
through the plastic bumper.
When I stopped he was angry and unwilling to accept any help, it was sad,
thousands of dollars worth of damage over a flat tire.
It was not either of the jacks fault that they had done all the damage to
the car, both jacks were able to do the job that they were designed for but
the guy was not trained in how to use them but felt he was smart enough to
know what he was doing.
Randy
www.s100-manuals.com
Agreed, but nor should anyone really care about
provable
correctness, right? Engineering is about making things that
are practically useful, i.e. "good enough"-- we're not
designing stained glass windows for the Church of Reason,
we're simply making and maintaining tools to solve todays
problems more efficiently than if those tools were not
available.
Certainly we should not immediately drop our coding sticks
and not touch them again until we _know_ we have attained
perfection. But I disagree strongly that we should not strive
to reach that goal.
If we had a mechanism now to create provably correct
programs (that met specifications that we could be
sure meant what we intended them to mean) - and
further assuming that use of such a mechanism did
not impose excessive cost or efficiency burdens etc, -
then I think we would have to use them for all
serious programs.
Given the choice, I'd prefer the programs I use to
work perfectly rather than imperfectly - and I'd prefer
to spend the time I program at work creating correct
code rather than being dragged back to fix yesterday's
mistake.
I'm more than willing to trade an occasional goto for that!
Antonio
9:45 p.m.
On 5/12/05, Antonio Carlini <a.carlini at ntlworld.com> wrote:
If we had a mechanism now to create provably correct
programs (that met specifications that we could be
sure meant what we intended them to mean) - and
further assuming that use of such a mechanism did
not impose excessive cost or efficiency burdens etc, -
then I think we would have to use them for all
serious programs.
That's a big if. I'm pretty well convinced it's a pipe dream. We'll
have reasoning machines capable of programming themselves when such a
scheme would prove useful (because I believe it is the same problem).
Of course if I had *this* I would use it (in fact, someone else would
be using it and I'd have to find a new line of work).
Today all you can do is trade a specification language for a
programming language. I think the programming language is the most
succinct, clear, and unambiguous specification language imaginable.
Almost always each construct has one and only one interpretation. You
cannot say anything in a programming language that cannot be done.
This is more clear on a small language like C or Forth or assembler
than it is in something like Perl or even C++. But true nonetheless
for those languages as well.
-- John.
13 May
13 May
1:38 p.m.
It was thus said that the Great John Hogerhuis once stated:
Today all you can do is trade a specification language for a
programming language. I think the programming language is the most
succinct, clear, and unambiguous specification language imaginable.
Almost always each construct has one and only one interpretation. You
cannot say anything in a programming language that cannot be done.
This is more clear on a small language like C or Forth or assembler
than it is in something like Perl or even C++. But true nonetheless
for those languages as well.
So, to tie this in with the Zen Koan threads, what is the result of
int i = 0;
printf("%d %d %d\n",i++,i++,i++);
(That's C code, just to let you know).
-spc (Who knows the answer and is driving you towards the murkier parts of
the C specification ... )
1:58 p.m.
On Fri, 13 May 2005, Bryan Pope wrote:
Not on my system:
0 1 2
Mike Loewen mloewen at cpumagic.scol.pa.us
The B9 Robot Builders Club B9-0014 http://ripsaw.cac.psu.edu/~mloewen/B9/
Old Technology http://ripsaw.cac.psu.edu/~mloewen/Oldtech/
So, to tie
this in with the Zen Koan threads, what is the result of
int i = 0;
printf("%d %d %d\n",i++,i++,i++);
IIRC it should output:
2 1 0 
2:07 p.m.
And thusly Mike Loewen spake:
On Fri, 13 May 2005, Bryan Pope wrote:
Not on my system:
0 1 2
I checked after I sent the message and my system output "2 1 0"... I am
using Watcom C 10.6 under QNX 4.25.
Cheers,
Bryan Pope
So, to
tie this in with the Zen Koan threads, what is the result of
int i = 0;
printf("%d %d %d\n",i++,i++,i++);
IIRC it should output:
2 1 0
2:24 p.m.
It was thus said that the Great Bryan Pope once stated:
And thusly Mike Loewen spake:
I was replying to this statement from John Hogerhuis:
On Fri, 13 May 2005, Bryan Pope wrote:
Not on my system:
0 1 2
I checked after I sent the message and my system output "2 1 0"... I am
using Watcom C 10.6 under QNX 4.25. So, to
tie this in with the Zen Koan threads, what is the result of
int i = 0;
printf("%d %d %d\n",i++,i++,i++);
IIRC it should output:
2 1 0 I think the programming language is the most
succinct, clear, and unambiguous specification language imaginable.
Almost always each construct has one and only one interpretation.
And this is a perfect example of what I was trying to get across (and so
far, no one has stated the correct answer, yet both Bryan's and Mike's
compilers have produced a correct answer. To add fuel to the conversation,
the IRIX 4.0.5 C compiler would produce
0 0 0
which is also a correct answer.
-spc (On topic, since this applies to C89 ... )
2:28 p.m.
And thusly Sean 'Captain Napalm' Conner spake:
It was thus said that the Great Bryan Pope once stated:
Now I am going to have to find my K & R book... I believe it says that
the order for a printf it right to left and since the "++" is after the
variable, the increment gets done after the value of retrieved.
Cheers,
Bryan Pope
And thusly Mike Loewen spake:
I was replying to this statement from John Hogerhuis:
On Fri, 13 May 2005, Bryan Pope wrote:
I checked after I sent the message and my system output "2 1 0"... I am
using Watcom C 10.6 under QNX 4.25. > So, to tie this in with the Zen Koan
threads, what is the result of
>
> int i = 0;
> printf("%d %d %d\n",i++,i++,i++);
>
IIRC it should output:
2 1 0
Not on my system:
0 1 2
I think the programming language is the most
succinct, clear, and unambiguous specification language imaginable.
Almost always each construct has one and only one interpretation.
And this is a perfect example of what I was trying to get across (and so
far, no one has stated the correct answer, yet both Bryan's and Mike's
compilers have produced a correct answer. To add fuel to the conversation,
the IRIX 4.0.5 C compiler would produce
0 0 0
which is also a correct answer.
3:21 p.m.
It was thus said that the Great Bryan Pope once stated:
And thusly Sean 'Captain Napalm' Conner spake:
The order of evaluation of parameters to a function go right to left (due
that functions can received a variable number of arguments, and *most*
implementations pass parameters on the stack (used to save return addresses)
it makes things consistent if you go right to left and have the return
address always in the same place on the stack when a function is
called---did that make sense?), *but* the writeback of the post-increment
(x++) can be held until the end of a sequence point (or statement, it's been
a while since I knew the actual details, since I know better than to write
such code 8-).
Just one of the murkier points of C.
-spc (Also, bare 'char' declarations can be signed or unsigned)
And this is a perfect example of what I was trying to get across (and so
far, no one has stated the correct answer, yet both Bryan's and Mike's
compilers have produced a correct answer. To add fuel to the conversation,
the IRIX 4.0.5 C compiler would produce
0 0 0
which is also a correct answer.
Now I am going to have to find my K & R book... I believe it says that
the order for a printf it right to left and since the "++" is after the
variable, the increment gets done after the value of retrieved. 
3:22 p.m.
Sean 'Captain Napalm'Conner wrote:
It was thus said that the Great Bryan Pope once
stated:
I checked after I sent the message and my system output "2 1 0"... I
am
For those of you playing the home version of the game...
It entirely depends on the definition of an "execution unit" which
is left up to the compiler vendor.
And thusly Mike Loewen spake:
>
> On Fri, 13 May 2005, Bryan Pope wrote:
>
> >> So, to tie this in with the Zen Koan threads, what is
the result
of
>
> int i = 0;
> printf("%d %d %d\n",i++,i++,i++);
>
IIRC it should output:
2 1 0
Not on my system:
0 1 2
using Watcom C 10.6 under QNX 4.25.
To add fuel to the conversation,
the IRIX 4.0.5 C compiler would produce
0 0 0
which is also a correct answer. 
2:24 p.m.
>>>> "Bryan" == Bryan Pope
<bpope at wordstock.com> writes:
Bryan> And thusly Mike Loewen spake:
> On Fri, 13 May 2005, Bryan Pope wrote:
>
> >> So, to tie this in with the Zen Koan threads, what is the
> result of
> >>
> >> int i = 0; >> printf("%d %d %d\n",i++,i++,i++);
> >>
> >
> > IIRC it should output:
> >
> > 2 1 0
>
> Not on my system:
>
> 0 1 2
>
Bryan> I checked after I sent the message and my system output "2 1
Bryan> 0"... I am using Watcom C 10.6 under QNX 4.25.
I think the answer is that it should display 3 numbers, each in the
range 0 to 2.
GCC produces 2 1 0 on x86 and 0 1 2 on MIPS.
paul
14 May
14 May
9:04 p.m.
>> >> int i = 0; >> printf("%d
%d %d\n",i++,i++,i++);
>> > IIRC it should output:
>>>>>>>>> AD NAUSEUM
Hey, WTF, over?! I thought you guys were all programmers?
The answer is: UNDEFINED. What it will print is UNDEFINED. Good
old K & R warns you of SIDE EFFECTS, most specifically
stupid-human assumptions about the order of evaluation.
Sheesh!
Try writing a portable printf(). Good luck!
15 May
15 May
10:42 p.m.
On Sat, 2005-05-14 at 18:04 -0700, Tom Jennings wrote:
No, it will not print "UNDEFINED" it will print something very well
defined.
Just not defined by the ANSI or ISO folks. It's defined by your friendly
neighborhood compiler writer.
In any event it may be stupid (and usually is) to create implementation
dependencies like this that a) are non-portable and b) are really hard
for joe-code-maintainer to understand without a well-crafted google
search.
Remember though that there are lots of cases where portability does not
matter. And if it's for your personal use joe-coder won't matter
either.
The only kind of software that matters is software that is compiled and
runs on a computer. One can only presume that it is (a) Real compiler(s)
and (a) Real computer(s) involved here, so all language implementation
and platform specific issues will be settled by reality.
The usual logic is to save yourself work later if it's easy to do
something different now. But you must always balance that against "You
Ain't Gonna Need It." One way to think of it is to maximize laziness
while meeting the hard requirements of functionality and schedule. They
don't pay you the big bucks to hit the would-be-nices, or to make a 6
level masterpiece of a class hierarchy, and certainly not to write an
entry for the obfuscated C contest, but rather to get it done as
required, on-time.
-- John.
>>
>> int i = 0; >> printf("%d %d %d\n",i++,i++,i++);
>> > IIRC it should output:
>>>>>>>>> AD NAUSEUM
Hey, WTF, over?! I thought you guys were all programmers?
The answer is: UNDEFINED. What it will print is UNDEFINED. Good
old K & R warns you of SIDE EFFECTS, most specifically
stupid-human assumptions about the order of evaluation.
16 May
16 May
2:23 p.m.
John R. Hogerhuis wrote:
On Sat, 2005-05-14 at 18:04 -0700, Tom Jennings wrote:
> The answer is: UNDEFINED. What it will print is
UNDEFINED.
> Good old K & R warns you of SIDE EFFECTS, most specifically
> stupid-human assumptions about the order of evaluation.
No, it will not print "UNDEFINED" it will
print something very
well defined.
Not true. It's UNDEFINED. There is no requirement to print
anything. Your compiler writer might have decided that the
compiler should stop at this point. Or it might emit a program
that halts at this point. Or anything else might happen.
You cannot be sure that the same thing will happen on
each run of the program (or of the compiler ...).
Just not defined by the ANSI or ISO folks. It's
defined by
your friendly neighborhood compiler writer.
I agree that it is unlikley that the compiler writer would
have spotted this condition and deliberately decided to
do something nasty and subtle (even though you quite
obviously deserve it for writing that code). But if the
compiler writer did spot it and didn't give you a clear
warning and refuse to produce any object code, then clearly
(s)he has an evil sense of humour, in which case all bets
are off! So you lose either way :-)
Your compiler might have been (partially) coded automatically
by mechanically translating some representation of the C language
(BNF or whatever). So it might well dive off into hyperspace
when it hits an undefined expression.
Antonio
--
---------------
Antonio Carlini arcarlini at iee.org
9:11 p.m.
On Mon, 16 May 2005 23:54:34 +0100 (BST)
ard at p850ug1.demon.co.uk (Tony Duell) wrote:
Steve Ciarcia used to say his favorite 'programming language' was
solder.
Hey, WTF,
over?! I thought you guys were all programmers?
Hey, I've never claimed to be a programmer. A hardware hacker, maybe,
but not a programmer...
-tony
9:22 p.m.
From: "Scott Stevens" <chenmel at earthlink.net>
Sent: Monday, May 16, 2005 8:11 PM
On Mon, 16 May 2005 23:54:34 +0100 (BST)
ard at p850ug1.demon.co.uk (Tony Duell) wrote:
Steve Ciarcia used to say his favorite 'programming language' was
solder.
On another list one person refused to call it programming when I said I
programmed with solder (diode matrix).
Randy
www.s100-manuals.com
Hey, WTF,
over?! I thought you guys were all programmers?
Hey, I've never claimed to be a programmer. A hardware hacker, maybe,
but not a programmer...
-tony 
17 May
17 May
7:01 p.m.
On Mon, 16 May 2005 23:54:34 +0100 (BST)
ard at p850ug1.demon.co.uk (Tony Duell) wrote:
Steve Ciarcia used to say his favorite 'programming language' was
solder.
I remember that...
Actually, I have modified a program using a soldering iron. I have the
M792 diode matrix boot ROM in my PDP11/45. Actually I have 2 of
them, one contain the paper tape bootstrap, the other the mass storage
device bootstrap. The latter will boot the RK05 (which i have), amongst
other devices -- to use it, you load 773100 (start address of the boot
ROM) into the address register, then put the CSR address for the selected
device on the switches, then START. Anyway there were a few unused
locations at the end of the ROM, so I soldered in the appropriate diodes
to load the right register with the RK11 CSR address and jump to the
right point in the ROM. The result is that I can leave the address of the
first of those instructions on the swtiches, then just hit LD ADDR and
START to boot the RK05.
-tony
Hey, WTF,
over?! I thought you guys were all programmers?
Hey, I've never claimed to be a programmer. A hardware hacker, maybe,
but not a programmer...
-tony 
14 May
14 May
9:59 p.m.
That's REALLY weird, endian issue or is that just undefined behavior
in the C spec?
On May 13, 2005, at 2:24 PM, Paul Koning wrote:
>>>> "Bryan" == Bryan Pope <bpope at wordstock.com> writes:
>>>>
Bryan> And thusly Mike Loewen spake:
> On Fri, 13 May 2005, Bryan Pope wrote:
>
>
>>> So, to tie this in with the Zen Koan threads, what is the
>>>
> result of
>
>>>
>>> int i = 0; >> printf("%d %d %d\n",i++,i++,i++);
>>>
>>>
>>
>> IIRC it should output:
>>
>> 2 1 0
>>
>
> Not on my system:
>
> 0 1 2
>
>
Bryan> I checked after I sent the message and my system output "2 1
Bryan> 0"... I am using Watcom C 10.6 under QNX 4.25.
I think the answer is that it should display 3 numbers, each in the
range 0 to 2.
GCC produces 2 1 0 on x86 and 0 1 2 on MIPS.
paul
15 May
15 May
11:49 p.m.
[quoting botches fixed, and vertically compressed, manually -dM]
That's REALLY weird, endian issue or is that just undefined behavior
in the C spec?
It's undefined behaviour, in the strict sense of "undefined" used in
the C spec. "3.1 d00d j00 l0se" would be just as conformant to the C
spec, as would a segfault (or whatever the equivalent is under the OS
in use). Of course, each implementation can be looked on as a spec
that defines behaviour for all the stuff that's undefined in the C
standard, but from that point of view there are as many specs as there
are implementations, so there is no "the" spec.
The difference observed in gcc-compiled code between x86 and MIPS is
probably related more to argument-passing conventions than endianness
issues, especially since that report didn't say whether the MIPS was
running LE or BE (MIPS can be either).
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>>> int i = 0; printf("%d %d
%d\n",i++,i++,i++);
>> IIRC it should output: 2 1 0
> Not on my system: 0 1 2
GCC produces 2 1 0 on x86 and 0 1 2 on MIPS.
16 May
16 May
9:42 a.m.
>>>> "Gary" == Gary Sparkes,
<Gary> writes:
Gary> That's REALLY weird, endian issue or is that just undefined
Gary> behavior in the C spec?
>> On May 13, 2005, at 2:24 PM, Paul
>> Koning wrote:
> GCC produces 2 1 0 on x86 and 0 1 2 on MIPS.
Undefined behavior, so both are correct.
I suspect the underlying cause is that x86 passes all args on the
stack, while MIPS passes the first four (or eight) in registers. So
the x86 code looks like this:
push 0
push 1
push 2
push (pointer to "%d %d %d")
call printf
while the MIPS code looks like
la a0, (pointer to "%d %d %d")
li a1, 0
li a2, 1
li a3, 2
jal printf
paul
12:35 p.m.
When I took C programming in high school, our teacher taught us how to use
goto, but if he saw it in our code, we had 30 seconds to justify it to his
satisfaction before he'd throw the eraser at us. He was a good shot, too ;)
Cheers,
--jpw
1:28 p.m.
It was thus said that the Great willisjo at zianet.com once stated:
When I took C programming in high school, our teacher taught us how to use
goto, but if he saw it in our code, we had 30 seconds to justify it to his
satisfaction before he'd throw the eraser at us. He was a good shot, too ;)
I've been programming in C since 1990, and in that time, I've only used
GOTOs under three conditions (as far as I can remember):
1. A function with a lot of cleanup required if it fails, so I use a
GOTO to clean up before returning an error; this is rare for me
though.
2. State machines. It keeps me sane. This is my biggest use of
GOTOs. My HTML parser has 22 GOTOs (22 states) and without the use
of GOTOs, the code would probably be more of a mess than it already
is.
3. *VERY* rarely, as a mechanism for exceptions, and then, I use
setjmp()/longjmp() (which are non-local GOTOs in C). I think I
played around with this a few times, but gave up on it (I don't
particularly care for the semantics of setjmp() and it has some
rather nasty restrictions on the return value).
-spc (I do tend though, to use multiple returns in a function ... )
2:38 p.m.
The other one I use it for is jumping past the top of a loop the first
time only (this code probably doesn't work but you get the idea...):
#define DIM(a) (sizeof (a) / sizeof (*(a)))
int ary[4] = {1,3,5,7};
.
.
.
print_ary (ary, DIM (ary));
void print_ary (int *aryp, int n)
{
goto skip_comma;
for (;n;aryp++, n--)
{
printf (", ");
skip_comma:
printf ("%u", *aryp);
}
printf ("\n");
}
State machines? If it is complex enough usually the better solution is
a two-way (current state, input) table of function pointers, unless
your implementation language doesn't support some analog to function
pointers...
-- John.
3:19 p.m.
John Hogerhuis wrote:
The other one I use it for is jumping past the top of
a loop the first
time only (this code probably doesn't work but you get the idea...):
#define DIM(a) (sizeof (a) / sizeof (*(a)))
int ary[4] = {1,3,5,7};
.
.
.
print_ary (ary, DIM (ary));
void print_ary (int *aryp, int n)
{
goto skip_comma;
for (;n;aryp++, n--)
{
printf (", ");
skip_comma:
printf ("%u", *aryp);
}
printf ("\n");
}
I'd do this, and didn't even know that jumping into the middle of the
FOR loop was legal. Even knowing it is legal, I prefer my way (of course):
void print_ary (int *aryp, int n)
{
int i;
for (i=0; i<n; aryp++, i++)
{
if (i>0)
printf (", ");
printf ("%u", *aryp);
}
printf ("\n");
}
3:26 p.m.
It was thus said that the Great Jim Battle once stated:
John Hogerhuis wrote:
I'd skip both the GOTO and the conditional and do it:
void print_ary(int *aryp,size_t n)
{
size_t i;
char *sep;
assert(aryp != NULL); /* sorry, gotta check */
assert(n > 0);
for (i = 0 , sep = "" ; i < n ; aryp++ , i++)
{
printf("%s%u",sep,&aryp);
sep = ",";
}
putchar('\n');
}
-spc (Who tries to avoid conditionals when possible ... )
The other one I use it for is jumping past the
top of a loop the first
time only (this code probably doesn't work but you get the idea...):
void print_ary (int *aryp, int n)
{
goto skip_comma;
for (;n;aryp++, n--)
{
printf (", ");
skip_comma:
printf ("%u", *aryp);
}
printf ("\n");
}
I'd do this, and didn't even know that jumping into the middle of the
FOR loop was legal. Even knowing it is legal, I prefer my way (of course):
void print_ary (int *aryp, int n)
{
int i;
for (i=0; i<n; aryp++, i++)
{
if (i>0)
printf (", ");
printf ("%u", *aryp);
}
printf ("\n");
}
3:37 p.m.
On 5/16/05, Sean 'Captain Napalm' Conner <spc at conman.org> wrote:
I'd skip both the GOTO and the conditional and
do it:
void print_ary(int *aryp,size_t n)
{
size_t i;
char *sep;
assert(aryp != NULL); /* sorry, gotta check */
assert(n > 0);
for (i = 0 , sep = "" ; i < n ; aryp++ , i++)
{
printf("%s%u",sep,&aryp);
sep = ",";
}
putchar('\n');
}
-spc (Who tries to avoid conditionals when possible ... )
Clever. I don't like the conditional either, but you are also
unnecessarily reinitializing sep every time through the loop. With the
goto I avoid both the conditional and the reinit.
In a way I guess I'm creating a new control structure (at least new to
me). Heck maybe I'll add it as a full bonified control structure in my
WP-2 Forth. Forth doesn't have goto, but it gives you the tools to
create your own control structures, so a good trade-off.
BTW, I think you mean *aryp not &aryp
-- John.
3:45 p.m.
On 5/16/05, Jim Battle <frustum at pacbell.net> wrote:
I'd do this, and didn't even know that jumping
into the middle of the
FOR loop was legal. Even knowing it is legal, I prefer my way (of course):
void print_ary (int *aryp, int n)
{
int i;
for (i=0; i<n; aryp++, i++)
{
if (i>0)
printf (", ");
printf ("%u", *aryp);
}
printf ("\n");
}
Jumping into a for loop is legal (in C anyway, problematic in C++ if
you're using automatic object variables w/ constructor that needs
executing on entry to the block). You miss the initializer altogether,
the test the first time through, but you'll hit the first increment at
the bottom of the loop.
I could do it your way, but it has an unnecessary conditional. Not a
big sacrifice, I admit. Not worth getting hit with an eraser anyway.
-- John.
6 p.m.
New subject: WAY OT NOW Re: 'goto" gone from computer languages or is it!
On Mon, 16 May 2005, Jim Battle wrote:
I'd do this, and didn't even know that jumping
into the middle of the
FOR loop was legal. Even knowing it is legal, I prefer my way (of course):
void print_ary (int *aryp, int n)
{
int i;
for (i=0; i<n; aryp++, i++)
{
if (i>0)
printf (", ");
printf ("%u", *aryp);
}
printf ("\n");
}
Um, if you're anal like me, you don't want to print a comma after the last
value, so:
...
printf ("%u", *aryp);
if (i<n) printf (", ");
...
Anyway, jumping into the middle of a loop as John prefers is, in my
opinion, horrible form ;)
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
5:12 p.m.
On Mon, 16 May 2005, Sean 'Captain Napalm' Conner wrote:
2. State machines. It keeps me sane. This is my
biggest use of
GOTOs. My HTML parser has 22 GOTOs (22 states) and without the use
of GOTOs, the code would probably be more of a mess than it already
is.
I always use a SWITCH construct inside a loop to accomplish this sort of
thing.
-spc (I do tend though, to use multiple returns in a
function ... )
Me too. I see no problem with that.
(As long as you properly clean up on your way out.)
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
15 May
15 May
7:05 p.m.
On 5/13/05, Paul Koning <pkoning at equallogic.com> wrote:
>> >> int i = 0; >> printf("%d
%d %d\n",i++,i++,i++);
I think the answer is that it should display 3
numbers, each in the
range 0 to 2.
That is the "likely" answer. (Actually I'd say that the "likely"
answer is that it prints three numbers in the range 0 to 2 and
afterwards the value of i is in the range 1 to 3)
There is no "should" answer. A compiler can do whatever it wants with
this code including generating an exception, printing the Gettysburg
address, and the aforementioned nasal demons.
Eric
13 May
13 May
2:26 p.m.
On Fri, 13 May 2005, Bryan Pope wrote:
And thusly Mike Loewen spake:
Interesting. Mine was gcc 3.42 under Solaris 2.9 (Ultra 10). Same
thing under AIX 4.3.3, with IBM's cc. However, under Linux (Redhat 7.1)
on an x86 platform with gcc 2.96, it gave "2 1 0".
Mike Loewen mloewen at cpumagic.scol.pa.us
The B9 Robot Builders Club B9-0014 http://ripsaw.cac.psu.edu/~mloewen/B9/
Old Technology http://ripsaw.cac.psu.edu/~mloewen/Oldtech/
On Fri, 13 May 2005, Bryan Pope wrote:
Not on my system:
0 1 2
I checked after I sent the message and my system output "2 1 0"... I am
using Watcom C 10.6 under QNX 4.25. So, to
tie this in with the Zen Koan threads, what is the result of
int i = 0;
printf("%d %d %d\n",i++,i++,i++);
IIRC it should output:
2 1 0
1:47 p.m.
Sean 'Captain Napalm' Conner wrote:
It was thus said that the Great John Hogerhuis once
stated:
> programming language. I think the programming
language is the
> most succinct, clear, and unambiguous specification language
So, to tie this in with the Zen Koan threads, what
is the
result of
int i = 0;
printf("%d %d %d\n",i++,i++,i++);
Your computer morphs into the Hitchhikers Guide To The Galaxy.
If you're lucky.
Antonio
--
---------------
Antonio Carlini arcarlini at iee.org
3:42 p.m.
Point taken; my first guess was 0 0 0, but it is apparently left
ambiguous by the standards committee. I did use the term "almost
always" to hedge, but still, you're right.
Nevertheless, for any given compiler there is only one interpretation.
So I hereby clarify my statement to say that programming languages as
implemented by actual compilers or interpreters are the most succinct,
clear and unambigious specification languages imaginable.
To another poster's point about "overspecification," I guess that's
true. So? That's what comments and thoughtful use of identifiers is
for.
Sorry my first couple of posts on the list are to OT threads. I'll try
to do better in the future :-)
-- John.
3:54 p.m.
>>>> "John" == John Hogerhuis
<jhoger at gmail.com> writes:
John> Point taken; my first guess was 0 0 0, but it is apparently
John> left ambiguous by the standards committee. I did use the term
John> "almost always" to hedge, but still, you're right.
Actually, I don't think the example was "ambiguous". It's
"undefined"
which is actually a term with a precise meaning. So you were right --
a program is a precise statement. But for some programs, that precise
statement doesn't define just one possible outcome.
A number of programming languages intentionally make certain things
unspecified, or undefined -- the reason for doing that is to give
implementations more choices and allow more efficient implementation.
The sample program that started this discussion is one example.
C isn't the only language that does this; Algol 68 is another. For
example, it quite explicitly and intentionally says that it's
unspecified whether the left or the right side of + (or neither) is
evaluated first.
John> Nevertheless, for any given compiler there is only one
John> interpretation. So I hereby clarify my statement to say that
John> programming languages as implemented by actual compilers or
John> interpreters are the most succinct, clear and unambigious
John> specification languages imaginable.
Not true. For example, you may have a program in which several things
happen in an order that depends on timing, or interrupts, or things
like that; if so, you may not get the same answer when you run it
twice. Embedded systems programmers are painfully familiar with this.
To use Algol 68 as an example again:
int i := 0;
int j := (i := i+1) + (i := i+1)
(which in C could be written as: j=(++i)+(++i) )
On completion, j might be 1 or 2, and i might be 1 or 2 -- and in
implementations that take advantage of paralellism, the answer might
change from run to run.
paul
4:22 p.m.
On 5/13/05, Paul Koning <pkoning at equallogic.com> wrote:
it
twice. Embedded systems programmers are painfully
familiar with this.
Well I don't know how painful I've found it (as an embedded systems
programmer). An interrupt is just another event source, albeit one
that must be handled with kid gloves. Your program will follow
different paths depending on the events inputs to it. Just because you
don't understand what has happened if you do a poor job on your
interrupt handler doesn't mean that the outcome isn't completely
predictable based on analysis of the code and understanding how the
machine works.
I have heard of systems where a randomness is allowed in: for example,
cases where FPGAs + genetic programming are used to evolve an
algorithm. It turns out that this can work, but unless you take
special measures you will end up with strange dependencies on noise
from the power source, etc.
-- John.
6:49 p.m.
Sean 'Captain Napalm' Conner wrote:
So, to tie this in with the Zen Koan threads, what
is the result of
int i = 0;
printf("%d %d %d\n",i++,i++,i++);
depends on the compiler. The spec leaves it open. gcc will likely do "0
1 2" but any where:
0 <= first <= second <= third <= 2
are valid iirc.
(That's C code, just to let you know).
-spc (Who knows the answer and is driving you towards the murkier parts of
the C specification ... )
--
Tim Riker - http://rikers.org/ - TimR at Debian.org
Embedded Linux Technologist
BZFlag maintainer - http://BZFlag.org/ - for fun!
7:08 p.m.
Tim Riker wrote:
depends on the compiler. The spec leaves it open. gcc
will
likely do "0 1 2" but any where:
0 <= first <= second <= third <= 2
are valid iirc.
undefined really does mean undefined. The compiler
could call printf with any three values it has lying
around and still be conforming.
The order of argument evaluation is explicitly left
unspecified so as to give the implementation more
freedom to optimise. There is no 1st,2nd,3rd -
the arguments might be evaluated from the middle
outwards or the outside inwards or whatever makes
sense. You cannot even assume that if you write
that line out twice, that the order of evaluation
will be the same the second time round. If the
printf is within a loop, the order of evaluation
might vary on each invocation. Optimisers do all
kinds of fun stuff!
Since the behaviour is undefined, anything can
happen. In practice the compiler won't turn
into a bowl of geraniums, but it could do something
far worse, and emit code that does whatever it is
that you might have expected. That way you think
you've written something reasonable only to find
that it all blows up horribly when the platform changes
or you get a new compiler or you update your
existing compiler or whatever. About the only thing
that is guaranteed is that, if you fall prey to
this problem, your QA org will miss the problem and
your customers will find it :-)
To top it all, you cannot even be sure what the
value of i will be after the call.
I think gcc 3.3 spots this kind of thing (and the
other common variant:
a[++i] = ++i;
Antonio
--
---------------
Antonio Carlini arcarlini at iee.org
7:55 p.m.
Antonio Carlini wrote:
[Snip]
I think gcc 3.3 spots this kind of thing (and the
other common variant:
a[++i] = ++i;
Jerome Fine replies:
I assume that the above statement could have two possible
interpretations:
(a) j = ++i; k = ++i; a[j] = k;
(b) j = ++i; k = ++i; a[k] = j;
(i) Are there any other interpretations? If so, what is the equivalent code?
(ii) Does gcc 3.3 produce a warning or an error message?
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
8:01 p.m.
a[++i] = ++i;
I assume that the above statement could have two possible
interpretations:
(a) j = ++i; k = ++i; a[j] = k;
(b) j = ++i; k = ++i; a[k] = j; (i) Are there any other interpretations?
Yes.
If so, what is the equivalent code?
There may not be any. When code wanders into realms specified to
produce undefined behaviour (as here, where i is modified twice without
an intervening sequence point), there is nothing compelling the
compiler to produce output that corresponds to any well-formed C code
at all. (I'm not even sure there's anything in the C spec calling for
the compiler to produce *any* output in such circumstances.)
If you want possible interpretations that *do* correspond to writable C
code, here's one for you:
a[i*i]=314156; i=a[0]/a[-1];
(Of course, a real compiler would be unlikely to do that....)
(ii) Does gcc 3.3 produce a warning or an error
message?
I don't know (and mostly don't care).
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
10:05 a.m.
Rumor has it that Antonio Carlini may have mentioned these words:
John Hogerhuis wrote:
<MODE="DevilsAdvocate">
Couple of things:
1) In a few instances, we should pick up those "coding sticks" and beat the
living *$&#^@~( out of a few people who should have never been allowed to
code in the first place... ;^>
2) Until we're all clones from a single gene base (and believe you me, you
don't wanna be *my* clone!!!), the goal of "perfection" is unattainable.
I'm not saying that we shouldn't *try*, for that will give us tools better
than what we have now -- but absolute perfection will not be the same for
all people.
Oh, and 3) If "perfection" actually did exist, I doubt any one of us on
this list could afford it... ;-)
Agreed, but nor should anyone really care about
provable
correctness, right? Engineering is about making things that
are practically useful, i.e. "good enough"-- we're not
designing stained glass windows for the Church of Reason,
we're simply making and maintaining tools to solve todays
problems more efficiently than if those tools were not
available.
Certainly we should not immediately drop our coding sticks
and not touch them again until we _know_ we have attained
perfection. But I disagree strongly that we should not strive
to reach that goal. If we had a mechanism now to create provably correct
programs (that met specifications that we could be
sure meant what we intended them to mean) - and
further assuming that use of such a mechanism did
not impose excessive cost or efficiency burdens etc, -
then I think we would have to use them for all
serious programs.
Gonna make sure I eat my vegetables, too? ;-)
What happens when the specification itself is wrong, or ambiguous, or
someone writes a virus that infects the "perfection checker" program?
I'd put a lot more faith into 10 people looking over each other's shoulders
than 1 computer program.
Given the choice, I'd prefer the programs I use to
work perfectly rather than imperfectly - and I'd prefer
to spend the time I program at work creating correct
code rather than being dragged back to fix yesterday's
mistake.
I'm more than willing to trade an occasional goto for that!
What happens if the only way to attain "programming perfection" is through
the use of gotos? ;-P
</MODE>
It's a grumpy Friday the 13th... I'll crawl back into my hole now.
;-)
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger | A new truth in advertising slogan
SysAdmin, Iceberg Computers | for MicroSoft: "We're not the oxy...
zmerch at 30below.com | ...in oxymoron!"
12 May
12 May
11:49 p.m.
So it's nothing to do with stifling your
creativity: be as creative
as you like. It's just unlikely that any of us (including you) will
ever know whether your prorams (or at least any of them of
significant size) are correct or not.
And this is just as true of people who use such formal methods. Manual
verification is as prone to errors as anything else humans do, and
automated verification involves programs far too large and complex to
be even moderately confident they're bug-free.
(Which is not to say that verifiers can't be useful tools. Just that
they don't provide the kind of "proof" level of confidence that your
implicit contrast implies you think they do.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
7007
days inactive
7012
days old
49 comments
23 participants
participants (23)
-
a.carlini＠ntlworld.com -
allain＠panix.com -
ard＠p850ug1.demon.co.uk -
bpope＠wordstock.com -
cctalk＠randy482.com -
chenmel＠earthlink.net -
dwight.elvey＠amd.com -
frustum＠pacbell.net -
jhfinexgs2＠compsys.to -
jhoger＠gmail.com -
jhoger＠pobox.com -
korpela＠gmail.com -
mloewen＠cpumagic.scol.pa.us -
mokuba＠gmail.com -
mouse＠Rodents.Montreal.QC.CA -
pkoning＠equallogic.com -
spc＠conman.org -
Tim＠rikers.org -
tomj＠wps.com -
vcf＠siconic.com -
wh.sudbrink＠verizon.net -
willisjo＠zianet.com -
zmerch＠30below.com