[9fans] same functions everywhere

[9fans] same functions everywhere

[rob pike, esq.]

> Doug is thinking ahead to C1x.

Surely the committee moves faster than this, and he's
really thinking of C0x.

-rob

Re: [9fans] same functions everywhere

[Jim Meier]

On Wed, 2003-04-30 at 21:24, rob pike, esq. wrote:
> > Doug is thinking ahead to C1x.
> Surely the committee moves faster than this, and he's
> really thinking of C0x.

Heh, fast commitees .. that's some funny stuff there
--
Jim Meier <jim@dsdd.org>

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>>// returns false if all slots do NOT equate to val
>>
>s/all slots do/any slot does/
>
You're, like, misreading the grammar.
If any of single slot does not equate to said value, then,
the slots, as a group, can not all equate to said value.
Like, for sure.

Re: [9fans] same functions everywhere

[Ralph Corderoy]

Hi Lucio,

> I don't go along with that.  Consider the conventional linear search
> of an array:
>
> 	int a[100];
> 	int x, v;
>
> 	...
>
> 	x = 0;
> 	while (x < 100 && a[x] != v) {
> 		++x;
> 	}
>
> (or whatever version you prefer).
>
> At the end, you always have to determine whether you found the desired
> element or exceeded the array bounds.
> ...
> This particular problem has bugged me for decades :-)  I go along with
> Doug that exception handling can hide the extremely uninteresting code
> involved in dealing with rare or "off band" conditions.

Python solves this particular problem like this:

    a = [1, 2, 3]

    for x in range(len(a)):
        if a[x] == 42:
            print x
            break
    else:
        print -1

The for's else clause is only executed if a natural end to the loop is
reached, i.e. you don't break out of it.

Cheers,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

Re: [9fans] same functions everywhere

[Ralph Corderoy]

Hi northern snowfall,

> // returns true if all slots EQUATE to val
> // returns false if all slots do NOT equate to val

s/all slots do/any slot does/

> // side effects: equates *pos to the first slot that tests false
> int
> gotvalue/*?*/(int * a, uint len, int val, uint * pos)
> {
>     uint ua;
>     for(ua = 0; ua < len; ua++) {
>         if(a[ua] != val) {
>             *pos = ua;
>             return false;
>         }
>     }
>     return true;
> }

99% of code comments in the world are worthless.

Tact-sucks-ly,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

Re: [9fans] same functions everywhere

[boyd, rounin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]

"Douglas A. Gwyn" <DAGwyn@null.net> a �crit dans le message de
news:3EBB29D8.7030200@null.net...
> Well, I don't want to get into a debate about that; suffice
> it to say that "get next character" is, to me, a function
> that cannot be performed when there is no next character ...

that's what peekc() macros are for :)

Re: [9fans] same functions everywhere

[Russ Cox]

> >You're all nuts.  But at least use nelem(a) in
> >place of sizeof(a)/sizeof(int).
>
> shouldn't that be called nwords/nints(a) or else shouldn't the
> expression be (sizeof(a)/sizeof(*(a)))?

No, it should be called nelem because it's defined (in libc.h):

#define	nelem(x)	(sizeof(x)/sizeof((x)[0]))

You've pointed out a bug in what they were using,
which was part of why I suggested nelem.

Re: [9fans] same functions everywhere

[Brian Inglis]

On Wed, 7 May 2003 14:45:22 GMT in comp.os.plan9,
rsc@plan9.bell-labs.com (Russ Cox) wrote:

>> Don't blame C, blame the coder.
>
>Love the sin, hate the sinner?
>
>[lots of thread snipped]
>
>You're all nuts.  But at least use nelem(a) in
>place of sizeof(a)/sizeof(int).

shouldn't that be called nwords/nints(a) or else shouldn't the
expression be (sizeof(a)/sizeof(*(a)))?

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
--
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

Re: [9fans] same functions everywhere

[boyd, rounin]

> cost <-> benefit

gee, i learn something every day ...

Re: [9fans] same functions everywhere

[boyd, rounin]

> Actually an integer value representable using CHAR_BIT bits.
> Even as of K&R 1st Ed. it wasn't necessarily exactly 8 bits.

8 bits != -1

Re: [9fans] same functions everywhere

[rog]

> > leaving safety-critical systems aside ...
>
> every system is 'safety-critical'; i want perfection ...

cost <-> benefit

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

"boyd, rounin" wrote:
> yup, getc() returns 8 bits.

Actually an integer value representable using CHAR_BIT bits.
Even as of K&R 1st Ed. it wasn't necessarily exactly 8 bits.

Re: [9fans] same functions everywhere

[boyd, rounin]

> The problem with embedded error recovery in predicate-transform
> approach is that the Boolean expressions become unwieldy very
> quickly; by their nature exceptional conditions are a wart that
> don't fit cleanly into the main logic flow.  If you cram them
> into the main flow anyway, then the complexity increases to the
> point that no programmer can completely grasp it.

spin

Re: [9fans] same functions everywhere

[boyd, rounin]

> leaving safety-critical systems aside ...

every system is 'safety-critical'; i want perfection ...

Re: [9fans] same functions everywhere

[rog]

> I agree with those here that hold the opinion that exceptions are no
> substitute for a well-thought-out and well-notated program (we used to
> call it "structured programming"). Need error handling obscure the
> "all's well" logic of the program?

leaving safety-critical systems aside (where every error *must* be
handled appropriately), there are runtime errors that can occur with
very low probability which mean that the program is unable to proceed.

in many programs, the only reasonable thing to do in such a case is to
exit.  in some others, there might be other actions that are worth
performing (e.g.  an editor might save current work; a multi-threaded
program might kill the other threads, etc).

if i wish to enable such a thing without any sort of exceptions, there
must be a return path back from *any* function that calls (directly or
indirectly) any other function that can incur one of these errors.

i.e.  it is never acceptable to write a function f returning type T
without also providing an additional error return (which must then be
propagated up the stack).

the additional error return, and the code necessary to check and
propagate the error, certainly seems like clutter to me, since i would
otherwise choose not to handle the error (or activate some
"fingers-crossed" recovery mechanism).  the exception mechanism also
enables me to catch errors generated by the run-time-system, where
there's no obvious place to handle the error (e.g.  stack overflow,
division by zero).

note that it's only clutter *because* i would have chosen not to try
to handle the error.  thus i would not count the error checking code
around fopen as clutter, because i will almost always choose to handle
that error appropriately (e.g.  by printing a sensible error message).

safety-critical systems are very different in this respect.  perhaps
in this kind of system, every division operation *should* have a check
for division by zero around it...

  cheers,
    rog.

Re: [9fans] same functions everywhere

[boyd, rounin]

> i'm slightly doubtful that the standard actually says 8 bits though.
> K&R just says "returns the next character", which could mean anything.

getc() always returned an int (>= 16 bits) and EOF was -1, so there is
no confusion.  get it wrong and it will bite you one day;  what was the
paper that described feeding 'random' bit stream into lunix (sic) filters?
i forget, but a lot of 'em broke.

    ashes to ashes
    dust to dust
    if you hack the kernel
    it's gonna bust

       -- bassoids

Re: [9fans] same functions everywhere

[rog]

> From: "Douglas A. Gwyn" <DAGwyn@null.net>
> > rog@vitanuova.com wrote:
> > > don't most >8bit character encodings (including unicode) provide at
> > > least one code point to represent "not a character"?
> >
> > We're not talking about character codes, but rather data
> > obtained via getc().  It could be an arbitrary binary stream.
>
> yup, getc() returns 8 bits.  it does not return unicode chars or unicode
> codespace characters.

if that's the case then doug's original objection isn't a problem, as
you're guaranteed that int has more than 8 bits, so there's always
space for a representation of EOF.

i'm slightly doubtful that the standard actually says 8 bits though.
K&R just says "returns the next character", which could mean anything.

Re: [9fans] same functions everywhere

[boyd, rounin]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> rog@vitanuova.com wrote:
> > don't most >8bit character encodings (including unicode) provide at
> > least one code point to represent "not a character"?
>
> We're not talking about character codes, but rather data
> obtained via getc().  It could be an arbitrary binary stream.

yup, getc() returns 8 bits.  it does not return unicode chars or unicode
codespace characters.

Re: [9fans] same functions everywhere

[boyd, rounin]

non local gotos are not your friend

Re: [9fans] same functions everywhere

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

I love religious arguments.

In #5ESS, error handling was a large % of the code.  It involved
in line checks, dead man timers, separate auditing systems,
and lots of code review to make sure there were no `don't care'
cases.  It was incredibly messy and fragile.  Exceptions might
have cleaned up some part of it but most of the process was
trying to avoid being sloppy.  Much of that could be
automated through tools, path analysis, and testing.

The complexity is still there with inline error handling or
exception mechanisms.  Separating the exception code can
(but not always will) clean up the main flow.  It also
reduces the number of places you can 'forget' to check.
Unfortunately, the further from the main flow it moves, the
less likely that it will be updated when the main flow changes.
This has caused us almost as many errors over time as missing
an exception case.  At the very least the exception catcher has to be in the
scope of what its cleaning up or everything (recoverable) in
the main flow has to be global.

However, the important part is handling all the possible
error states. The really unforseen ones (except for the odd
nil pointer reference or divide by zero) don't throw
exceptions.  In #5ESS, the auditing code was the mechanism
for these kinds of errors.  The auditing code continually
scanned the state of switch boards, processes, and memory
to make sure states didn't exist that were considered
'impossible'.  Of course this meant enumerating forseen
states.  If you stepped outside of the forseen, it was
time for action (reset the switch, kill processes, switch
to another processor, ...).  This is a really hard way to
 program and not something I'ld normally do.

[-- Attachment #2: Type: message/rfc822, Size: 2626 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
Date: Mon, 12 May 2003 08:56:43 GMT
Message-ID: <3EBDBBDC.3090300@null.net>

John Murdie wrote:
> (To counter my own argument, though, I remember reading something that -
> I think - Doug McIlroy wrote about error handling code in telephone
> exchanges; the code had been known to recover successfully from errors
> that the designers had not anticipated. That said, I'd rather not trust
> to such luck.)

The point is, it wasn't luck, but rather a global strategy that
would handle whatever had not been explcitly identified in
advance as a possible problem.

The problem with embedded error recovery in predicate-transform
approach is that the Boolean expressions become unwieldy very
quickly; by their nature exceptional conditions are a wart that
don't fit cleanly into the main logic flow.  If you cram them
into the main flow anyway, then the complexity increases to the
point that no programmer can completely grasp it.

Of course, for "toy systems" almost anything will work if
enough thought goes into it, but for large, intrinsically
messy systems, methodology for bringing complexity under control
is essential.

Re: [9fans] same functions everywhere

[boyd, rounin]

digital telephony, 2nd ed, john bellamy

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

John Murdie wrote:
> (To counter my own argument, though, I remember reading something that -
> I think - Doug McIlroy wrote about error handling code in telephone
> exchanges; the code had been known to recover successfully from errors
> that the designers had not anticipated. That said, I'd rather not trust
> to such luck.)

The point is, it wasn't luck, but rather a global strategy that
would handle whatever had not been explcitly identified in
advance as a possible problem.

The problem with embedded error recovery in predicate-transform
approach is that the Boolean expressions become unwieldy very
quickly; by their nature exceptional conditions are a wart that
don't fit cleanly into the main logic flow.  If you cram them
into the main flow anyway, then the complexity increases to the
point that no programmer can completely grasp it.

Of course, for "toy systems" almost anything will work if
enough thought goes into it, but for large, intrinsically
messy systems, methodology for bringing complexity under control
is essential.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> don't most >8bit character encodings (including unicode) provide at
> least one code point to represent "not a character"?

We're not talking about character codes, but rather data
obtained via getc().  It could be an arbitrary binary stream.

Re: [9fans] same functions everywhere

[boyd, rounin]

NASA used to build spacecraft; top down design, bottom up implementation.

now they 'build the shuttle'.

grissom is dead because of their own 'failure of vision';  the gemini mission
where the exploding bolts fired, so they removed 'em and so we had O2 +
velcro + a spark --- all of 'em dead ...

Re: [9fans] same functions everywhere

[boyd, rounin]

From: "John Murdie" <john@cs.york.ac.uk>
> I think that exceptions encourage careless, lazy, analysis and
> programming, and produce code that is unclear and (more) difficult to
> reason about than traditional sequential, predicate-transforming, code.
> Yes, they can be used as a short-hand notation to code e.g. the rule
> "whenever an arithmetic overflow occurs in this section of code, I don't
> care; just quit (or do the calculation again with different parameters,
> or whatever)", but they are also used as an inadequate substitute for
> proper systems analysis and coding.

like when the F-16 rolled inverted when it crossed the equator when flying
south.

Re: [9fans] same functions everywhere

[John Murdie]

On Fri, 2003-05-09 at 19:24, northern snowfall wrote:
> >
> >
> >And then what should one do? Suppose that a "genuinely surprising
> >condition" occurs when a launch vehicle is a few tens of seconds off the
> >ground; just what should the program do?
> >
> Hopefully, the programmer would have enough sense to
> see this coming? The point of smart design is to facilitate
> the unexpected, I don't think that means exceptions are
> the answer. Certainly, this argument is slightly dramatic,
> wouldn't you agree, John?

That's precisely my point (and, yes, it is slightly dramatic but, then,
people do code launch vehicle control systems). I'm glad we agree. I
would hope that the analyst/programmer[s] would have designed the code
in such a way that it straightforwardly describes what should be done in
all anticipatable circumstances. I don't think it is worth betting that
ad hoc exception-handling code can cope with the "genuinely surprising
condition".

I think that exceptions encourage careless, lazy, analysis and
programming, and produce code that is unclear and (more) difficult to
reason about than traditional sequential, predicate-transforming, code.
Yes, they can be used as a short-hand notation to code e.g. the rule
"whenever an arithmetic overflow occurs in this section of code, I don't
care; just quit (or do the calculation again with different parameters,
or whatever)", but they are also used as an inadequate substitute for
proper systems analysis and coding. I think that this was Rob Pike's
point, with which I agree.

(To counter my own argument, though, I remember reading something that -
I think - Doug McIlroy wrote about error handling code in telephone
exchanges; the code had been known to recover successfully from errors
that the designers had not anticipated. That said, I'd rather not trust
to such luck.)

John A. Murdie

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>And then what should one do? Suppose that a "genuinely surprising
>condition" occurs when a launch vehicle is a few tens of seconds off the
>ground; just what should the program do?
>
Hopefully, the programmer would have enough sense to
see this coming? The point of smart design is to facilitate
the unexpected, I don't think that means exceptions are
the answer. Certainly, this argument is slightly dramatic,
wouldn't you agree, John?
When I look at exceptions in C, I think mainly of sigjmp
(and to a lesser extent, goto). Though, this still doesn't
eradicate the problem that manfiested the exception. A
good example is the recent exploit I wrote for sendmail
version 8.12.8. Since version 8.12.8, itself, emulated an
exception on detection of invalid lengths in the prescan()
function, the exploitation technique for versions <8.12.8
was moot, since prescan() never returned. Instead, a
sigjmp_buf was used to reconstruct the execution
environment as it would have looked well before the
call to prescan(). However, I noticed that certain code
paths to prescan() allocated a small enough amount of
stack for me to reach the actual sigjmp_buf. On UNIX,
the first address stored in a sigjmp_buf is the EIP to be
entered on longjmp-and-friends. Able to overwrite this
EIP with values that would redirect code execution (still
in the valid code segment) to a place that would then
create a secondary vuln:
    e.g. assembly code used to call (*fp->{read, ... })(...
        mov (0x44)%ebx, %eax
        call *%eax
Thus, in very limited situations, I was still able to get
my malicious code, pumped in from the network, run.

This situation is a great example of a "genuinely
surprising condition", and the writers did a good job
to eradicate the easier frame-pointer-overwrite
technique. However, I was still able to assert control
of the target. In a more volatile situation (launch vehicle?)
is this good enough? This is what makes me think that
exception handlers are still secondary to forcing our
developers to take the time to think about the repercussions
of their work: whether it be an addendum, redesign, fresh
write, etc. Well designed code can still be flexible in all
given situations, even the unexpected. However,
implementing exceptions simply because you *think*
that might make things better (as opposed to taking a
look at the big picture) might just change the scope of
the problem.
Don

Re: [9fans] same functions everywhere

[Dan Cross]

> exceptions are surprising things: they do not facilitate linear
> reading of the code; they should be kept for genuinely surprising
> conditions.

I think this kind of depends on the syntax.  I once saw a proposed syntax
for Limbo (due to  Michael Baldwin, inspired by Icon, perhaps) that I
thought was really great; it looked something like:

	thing = function(foo, bar, baz); ! { exception handler, note bang }

The ability to station an exception handler after a statement using
the bang syntax gave one the `feeling' of programming without exceptions,
but also allowed one to move the error handling to a potentially more
appropriate place.  You could write code like:

	if (a == SYMBOLIC_CONSTANT) {
		str := string arr;
		b := a / 2;
		mod = load Mod Mod->PATH;
	} ! { sys->print("Something bad happened.\n"); }

It was very unintrusive, and I liked it a lot.

	- Dan C.

Re: [9fans] same functions everywhere

[John Murdie]

On Fri, 2003-05-09 at 14:21, rog@vitanuova.com wrote:
> DAGwyn@null.net:
> > when sizeof(char)==
> > sizeof(int) it is very likely that all-one bits is a valid
> > data value *as well as* the EOF marker
>
> don't most >8bit character encodings (including unicode) provide at
> least one code point to represent "not a character"?
>
> anyway, i'm not arguing about the design of getc.  maybe it should
> have been
>
> 	int getc(FILE *f, char *c);
>
> filling in the character at c iff it returns 1.  some of the plan 9
> rune(2) functions work in this kind of way.
>
> however, i would argue that using exceptions for such a thing would be
> fairly unwieldy, and end up obfuscating what should be plain,
> straightforward code.
>
> exceptions are surprising things: they do not facilitate linear
> reading of the code; they should be kept for genuinely surprising
> conditions.

And then what should one do? Suppose that a "genuinely surprising
condition" occurs when a launch vehicle is a few tens of seconds off the
ground; just what should the program do?

I agree with those here that hold the opinion that exceptions are no
substitute for a well-thought-out and well-notated program (we used to
call it "structured programming"). Need error handling obscure the
"all's well" logic of the program?

John A. Murdie
Department of Computer Science
University of York
UK

Re: [9fans] same functions everywhere

[rog]

DAGwyn@null.net:
> when sizeof(char)==
> sizeof(int) it is very likely that all-one bits is a valid
> data value *as well as* the EOF marker

don't most >8bit character encodings (including unicode) provide at
least one code point to represent "not a character"?

anyway, i'm not arguing about the design of getc.  maybe it should
have been

	int getc(FILE *f, char *c);

filling in the character at c iff it returns 1.  some of the plan 9
rune(2) functions work in this kind of way.

however, i would argue that using exceptions for such a thing would be
fairly unwieldy, and end up obfuscating what should be plain,
straightforward code.

exceptions are surprising things: they do not facilitate linear
reading of the code; they should be kept for genuinely surprising
conditions.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

Dan Cross wrote:
> Sounds like a good candidate for writing in C++ or a similar language.

No, that was not an option.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> it's a perfectly good kind of data - EOF is only out of band if one
> doesn't consider "not EOF" to be part of the normal getc return value.

Well, I don't want to get into a debate about that; suffice
it to say that "get next character" is, to me, a function
that cannot be performed when there is no next character,
thus something out of the ordinary has to occur, and making
it occur in the data channel constitutes, to me, an in-band
signal.  Note that this design causes very real problems
for portable C programming, because when sizeof(char)==
sizeof(int) it is very likely that all-one bits is a valid
data value *as well as* the EOF marker, so the program has
to perform an additional feof() test that would not be
necessary if the two kinds of information had been kept
separate.

Re: [9fans] same functions everywhere

[rog]

> This is fine, but one question I have is why cut and paste instead of
> putting sort() and mergesort() into their own file and then including
> it after defining T and greater()?  Just curious.

lack of surprises.  if i see that a source file has been included, i
have no idea what names the namespace has been polluted with.

one thing that's particularly nice about limbo is that, with the
necessary exception of module names, if i see a name referred to, i
can find out what it refers to very quickly and surely in the local
source file (defined locally, or explicitly imported from a module).

the moment i start including external source code, i'm again awash in
a sea of uncertainty.

much better to explicitly include the code: it keeps the code
dependencies as narrow as the module interfaces that have been
included, which are easy to understand, well-defined and well-behaved
(no callbacks, for example).

whenever i've had to make significant changes to an interface that's
used by many modules, the fact that all dependencies are explicitly
defined, and all names explicitly declared has made life soooo much
easier and less error-prone.  it makes for code that is much more
malleable and reusable (despite the apparent contradiction with Limbo
being such a strongly typed language).

sorry, this has veered way off topic!

Re: [9fans] same functions everywhere

[Dan Cross]

> > This is fine, but one question I have is why cut and paste instead of
> > putting sort() and mergesort() into their own file and then including
> > it after defining T and greater()?  Just curious.
>
> lack of surprises.  if i see that a source file has been included, i
> have no idea what names the namespace has been polluted with.

Granted, but as you noted yourself, this is a rather special case.
Anyway, I was just curious.

> sorry, this has veered way off topic!

Indeed it has, but that was a great explanation.  Thanks, Rog.

	- Dan C.

Re: [9fans] same functions everywhere

[Dan Cross]

> to be honest, where i've needed to sort something, i just paste in the
> following code:
>
> [snip]
>
> and define suitable values for T and greater(),
> e.g.
> T: type int;
> greater(a, b: int): int
> {
> 	return a>b;
> }
>
> the function itself is byte-for-byte identical with the other places
> it's used, and well debugged.
>
> since the actual code doesn't need to change at all, it's easily
> verified as being the same as that in other places (and easily
> searched for should a bug emerge.  there are a few.
>
> i dislike cut&paste code in other circumstances, but this seems
> different (as the code itself doesn't change, and the interface is
> very narrow).  maybe i'm hopelessly misguided!

This is fine, but one question I have is why cut and paste instead of
putting sort() and mergesort() into their own file and then including
it after defining T and greater()?  Just curious.

	- Dan C.

Re: [9fans] same functions everywhere

[rog]

> How do you write a generic sort function in Limbo?

there are several ways, most of which would be considered too
heavyweight for a simple sort, but which can be fine for larger
operations when generic behaviour is required (channels and modules
both provide different kinds of dynamic coupling).

as dan says, the new parametric polymorphism will provide a more
conventional way to do it: it's not *completely* generic (the
polymorphism only works on ref adts), but fine for many purposes.

to be honest, low level generic functionality like that doesn't seem
to be actually used *that* often.  (it's fairly unusual to need to
sort more than one kind of thing in a given module).

to be honest, where i've needed to sort something, i just paste in the
following code:

sort(a: array of T)
{
	mergesort(a, array[len a] of T);
}
mergesort(a, b: array of T)
{
	r := len a;
	if (r > 1) {
		m := (r-1)/2 + 1;
		mergesort(a[0:m], b[0:m]);
		mergesort(a[m:], b[m:]);
		b[0:] = a;
		for ((i, j, k) := (0, m, 0); i < m && j < r; k++) {
			if(greater(b[i], b[j]))
				a[k] = b[j++];
			else
				a[k] = b[i++];
		}
		if (i < m)
			a[k:] = b[i:m];
		else if (j < r)
			a[k:] = b[j:r];
	}
}

and define suitable values for T and greater(),
e.g.
T: type int;
greater(a, b: int): int
{
	return a>b;
}

the function itself is byte-for-byte identical with the other places
it's used, and well debugged.

since the actual code doesn't need to change at all, it's easily
verified as being the same as that in other places (and easily
searched for should a bug emerge.  there are a few.

i dislike cut&paste code in other circumstances, but this seems
different (as the code itself doesn't change, and the interface is
very narrow).  maybe i'm hopelessly misguided!

  cheers,
    rog.

PS. the other dynamic features of limbo mean *far* more
to me in terms of writing re-usable, re-applicable and
understandable, reasonable code than the lack of polymorphism.

Re: [9fans] same functions everywhere

[Dan Cross]

> once you're holding a huge bag of code, you've already lost the game.
> all the different pieces are too intertwined, regardless of how well
> you encapsulate or w'ever within the language.

Well, once you put the application logic into the domain of some
network system, it could be argued that you're tied to that network
system.  This may or may not be beneficial.  Sometimes that introduces
complexity that shouldn't exist (consider all the Corba cruft under
Unix et al, or how complex J2EE is; in both cases, you're trying to
distributed things in some way so that the code isn't centralized).

> IP, pipe streams and file object namespaces are good; concerning yourself w/
> how you link some language into a C library is bad.

This is noble, but somewhat misguided.  Russ was right; what do you
do when you're supplied with a library that's in C only?  You need
some way to interface with it.  Sure, you might build some sort of
network server that provides a file hierarchy for accessing the
functionality of the library, but sometimes (often) that's neither
possible nor warranted; calling a C routine from C++ is really trivial.
It'd be a step in the wrong direction to build a network server for it
just so I could call a function.  It's less trivial in Python, but
still easy.

> managing application complexity by building a more complex language
> seems a tad misguided.

Don't confuse managing complexity with eliminating complexity.
Building exception handling packages for C is introducing complexity
that doesn't exist when you use a language that supports exceptions
natively.  You aren't ``building'' a more complex language necessarily,
but rather making use of a pre-existing language that provides
functionality you'd have to otherwise build yourself.  In the C example,
you're trying to manage complexity.  In the `other language' example,
you're eliminating it.  Similarly with things like generic dictionary
objects; building hash tables in C is easy, but tedious and thus error
prone.  It adds complexity that wouldn't otherwise exist if I had a
generic container object.

> in this day and age, w/ all the talk going into "emergent behaviors",
> complex systems, etc, i'm surprised to hear people arguing for monolithic
> designs that specify brittle internal procedure and process, rather than
> simple designs that define simple interactions.

You can't make *everything* modular.  Or, rather, you might be able to
but it might not be the best idea.  Consider the fmt library; you could
define a network server just to handle I/O, and pass messages to it,
but why?  It's much easier and more intuitive to call print() and have
it do the work itself.  (Of course, in effect, the kernel acts kind of
like a network server that does the real work).  Or a more basic
example, calculating a square root.  Does it make sense to pass a
floating point number over the network to a server that does that and
then returns the result?  Not really, unless you're doing something
really specialized.

Of course, the above two examples are *really* contrived, and I'd go so
far as to say kind of stupid, but they illustrate a general idea:
sometimes it's just not worth it to make things more modular than they
have to be.

	- Dan C.

Re: [9fans] same functions everywhere

[Dan Cross]

> You guys are headed down the wrong track.
>
> The right way to program is with small modules written in several
> different languages which are meant for specific purposes.

Uhh, that's what I said, no?

	- Dan C.

Re: [9fans] same functions everywhere

[Dan Cross]

> > No, Limbo.
>
> How do you write a generic sort function in Limbo?

I had fun once writing a set of modules that allowed me to plug in
different sorting algorithms really easily at run time.  But you're
talking about what you're sorting, not how you're sorting it.  I
suspect games could be played with modules; maybe not, but the work
on parametric polymorphism that's being implemented for consideration
for Inferno 4th edition looks promising.

	- Dan C.

http://www.vitanuova.com/inferno/4e/limbo2.html

Re: [9fans] same functions everywhere

[Charles Forsyth]

>>Is there any data available on the exception handling in the new Limbo?
>>(syntax, implementation, etc)

i was planning to post my thoughts about the topic,
but i haven't had a chance to compose it yet.  i agreed with rob's
comments.  yet i had Limbo extended to support exceptions in
the language (they were already in the system).  is there a contradiction?
not really, but that's the bit i haven't had time to write yet!
i'll try to find time to do it tomorrow.

Re: [9fans] same functions everywhere

[Scott Schwartz]

> No, Limbo.

How do you write a generic sort function in Limbo?

Re: [9fans] same functions everywhere

[Joel Salomon]

> > > C doesn't need a low-level string type, nor does it need exceptions; what
> > > programmers who are looking for those things need to do is look for
> > > another language.
> >
> > And what language is going to give it to them?  C++?  Ha.  Ha ha ha.
>
> No, Limbo.
 From http://www.vitanuova.com/inferno/4e/limbo1.html:

> We have added exception handling to the Limbo language, replacing
> sys->rescue etc. This is intended to make it more straightforward to
> write fault-tolerant subsystems.
clip..
> The source changes to Limbo applications are relatively small, and the
> result is tidier.

Is there any data available on the exception handling in the new Limbo?
(syntax, implementation, etc)

I'd like to see what a "good" (in labs/vitanuova developer's view)
implimentation of exceptions looks like.

--Joel

Re: [9fans] same functions everywhere

[William Ahern]

On Thu, May 08, 2003 at 11:21:21AM -0700, root wrote:
> You guys are headed down the wrong track.
>
> The right way to program is with small modules written in several
> different languages which are meant for specific purposes.
>
> -Phil/CERisE

yeah. and isn't this the philosophy behind Unix and Plan 9? that is, a
system that defines a very generic, very abstract and yet very simple means
for inter-process communication?

once you're holding a huge bag of code, you've already lost the game.
all the different pieces are too intertwined, regardless of how well
you encapsulate or w'ever within the language.

IP, pipe streams and file object namespaces are good; concerning yourself w/
how you link some language into a C library is bad.

managing application complexity by building a more complex language
seems a tad misguided.

in this day and age, w/ all the talk going into "emergent behaviors",
complex systems, etc, i'm surprised to hear people arguing for monolithic
designs that specify brittle internal procedure and process, rather than
simple designs that define simple interactions.

Re: [9fans] same functions everywhere

[root]

You guys are headed down the wrong track.

The right way to program is with small modules written in several
different languages which are meant for specific purposes.

-Phil/CERisE

On Thu, May 08, 2003 at 02:14:53PM -0400, Dan Cross wrote:
> You totally missed my point.  What I was trying to convey is that one
> size doesn't fit all; there's no one single language for doing everything,
> but people tend to take a language and stick to it like glue, no matter
> that it might not be the best candidate for any given job.
>
> > > Sounds like a good candidate for writing in C++ or a similar language.
>                                                     ^^^^^^^^^^^^^^^^^^^^^
> > > C isn't optimal for writing really big applications; it's great for
> > > smaller things like utilities, text editors, systems software, etc.
> > > But it's frankly inconvenient for building huge programs.  It's just
> > > too low-level.  E.g., if I ever have to write another hashing function
> > > to try and implement some sort of string-based lookup again, I'll
> > > scream.
> >
> > All this and more can be said of C++.
>
> Perhaps.  However, note that I said, ``or a similar language.''  C++ is
> a contrived example.  However, I don't need to add a string type or
> exceptions to it, and the STL more or less eliminates the need to
> write stuff like linked lists or growable arrays or generic dictionary
> containers.  That's a win if I want to get something done, and not
> fiddle around with a lot of low-level details.  From the sounds of Doug's
> example, he had to do a lot of low-level wrangling.
>
> > > I don't understand why everyone feels the need to try and shoehorn
> > > their favorite language into every conceivable problem domain.
> >
> > Because when you start out writing a program in one language,
> > once you get a lot of code written it's costly to switch to another.
> > Or maybe you want to use some outside libraries available only in C.
>
> Continuing the C++ example, C++ makes it very easy to call C code.  In
> fact, I'd go so far as to say that most languages one might seriously
> consider for writing big applications do.
>
> > > C doesn't need a low-level string type, nor does it need exceptions; what
> > > programmers who are looking for those things need to do is look for
> > > another language.
> >
> > And what language is going to give it to them?  C++?  Ha.  Ha ha ha.
>
> No, Limbo.
>
> C++ *does* give you a string type and exceptions.  Is it suitable for
> every job?  No, but I never said it was.  In fact, my point was that no
> single language is.  Once again, the use of C++ was a contrived example.
>
> > What happens when C++ is too low-level for the job at hand?  It's not
> > any more malleable than C is (though it is quite a bit more amorphous).
>
> So use something else.
>
> There are any number of languages available to fill all kinds of roles.
> Use whatever fits.
>
> > I've been looking for another language for a few years now, and I
> > don't see it.  Would you have us not write programs because there's
> > no good language to write them in?
>
> What part of what I wrote makes you think that's what I meant?
>
> > Claiming that the language designer will correctly anticipate the
> > exact level of abstraction required for your huge program is ridiculous.
>
> I don't recall ever making that claim.  Perhaps you can cite where I did.
>
> I do recall claiming that no one language is suitable for every
> application domain, and that trying to shoehorn C into being so is a
> mistake.
>
> > The programmer has to be able to build up abstractions as necessary.
>
> Agreed.
>
> > And you can do this in C as well as you can in any of the other languages
> > commonly used for systems programming.
>
> Note that I mentioned ``applications programming,'' not just ``systems
> programming.''  For systems programming, you're right.  For applications
> programming, you're not.
>
> > The only language that facilitates programmer-based extension
> > outstandingly well is Lisp, but Lisp has other problems.
>
> That's subjective.  I could argue that any number of functional
> programming languages do just as good a job as Lisp in this arena.
>
> But hell, why don't we all just program in some kind of generic
> assembly language?  We can define a set of opcodes that map to useful
> operations, and build a macro assembler that provides a generic string
> type and exceptions.  And why have a seperate shell language that we
> write scripts in?  Why not write everything as a C program?
>
> 	- Dan ``One size doesn't fit all'' C.
>

Re: [9fans] same functions everywhere

[Dan Cross]

You totally missed my point.  What I was trying to convey is that one
size doesn't fit all; there's no one single language for doing everything,
but people tend to take a language and stick to it like glue, no matter
that it might not be the best candidate for any given job.

> > Sounds like a good candidate for writing in C++ or a similar language.
                                                    ^^^^^^^^^^^^^^^^^^^^^
> > C isn't optimal for writing really big applications; it's great for
> > smaller things like utilities, text editors, systems software, etc.
> > But it's frankly inconvenient for building huge programs.  It's just
> > too low-level.  E.g., if I ever have to write another hashing function
> > to try and implement some sort of string-based lookup again, I'll
> > scream.
>
> All this and more can be said of C++.

Perhaps.  However, note that I said, ``or a similar language.''  C++ is
a contrived example.  However, I don't need to add a string type or
exceptions to it, and the STL more or less eliminates the need to
write stuff like linked lists or growable arrays or generic dictionary
containers.  That's a win if I want to get something done, and not
fiddle around with a lot of low-level details.  From the sounds of Doug's
example, he had to do a lot of low-level wrangling.

> > I don't understand why everyone feels the need to try and shoehorn
> > their favorite language into every conceivable problem domain.
>
> Because when you start out writing a program in one language,
> once you get a lot of code written it's costly to switch to another.
> Or maybe you want to use some outside libraries available only in C.

Continuing the C++ example, C++ makes it very easy to call C code.  In
fact, I'd go so far as to say that most languages one might seriously
consider for writing big applications do.

> > C doesn't need a low-level string type, nor does it need exceptions; what
> > programmers who are looking for those things need to do is look for
> > another language.
>
> And what language is going to give it to them?  C++?  Ha.  Ha ha ha.

No, Limbo.

C++ *does* give you a string type and exceptions.  Is it suitable for
every job?  No, but I never said it was.  In fact, my point was that no
single language is.  Once again, the use of C++ was a contrived example.

> What happens when C++ is too low-level for the job at hand?  It's not
> any more malleable than C is (though it is quite a bit more amorphous).

So use something else.

There are any number of languages available to fill all kinds of roles.
Use whatever fits.

> I've been looking for another language for a few years now, and I
> don't see it.  Would you have us not write programs because there's
> no good language to write them in?

What part of what I wrote makes you think that's what I meant?

> Claiming that the language designer will correctly anticipate the
> exact level of abstraction required for your huge program is ridiculous.

I don't recall ever making that claim.  Perhaps you can cite where I did.

I do recall claiming that no one language is suitable for every
application domain, and that trying to shoehorn C into being so is a
mistake.

> The programmer has to be able to build up abstractions as necessary.

Agreed.

> And you can do this in C as well as you can in any of the other languages
> commonly used for systems programming.

Note that I mentioned ``applications programming,'' not just ``systems
programming.''  For systems programming, you're right.  For applications
programming, you're not.

> The only language that facilitates programmer-based extension
> outstandingly well is Lisp, but Lisp has other problems.

That's subjective.  I could argue that any number of functional
programming languages do just as good a job as Lisp in this arena.

But hell, why don't we all just program in some kind of generic
assembly language?  We can define a set of opcodes that map to useful
operations, and build a macro assembler that provides a generic string
type and exceptions.  And why have a seperate shell language that we
write scripts in?  Why not write everything as a C program?

	- Dan ``One size doesn't fit all'' C.

Re: [9fans] same functions everywhere

[Russ Cox]

> Sounds like a good candidate for writing in C++ or a similar language.
> C isn't optimal for writing really big applications; it's great for
> smaller things like utilities, text editors, systems software, etc.
> But it's frankly inconvenient for building huge programs.  It's just
> too low-level.  E.g., if I ever have to write another hashing function
> to try and implement some sort of string-based lookup again, I'll
> scream.

All this and more can be said of C++.

> I don't understand why everyone feels the need to try and shoehorn
> their favorite language into every conceivable problem domain.

Because when you start out writing a program in one language,
once you get a lot of code written it's costly to switch to another.
Or maybe you want to use some outside libraries available only in C.

> C doesn't need a low-level string type, nor does it need exceptions; what
> programmers who are looking for those things need to do is look for
> another language.

And what language is going to give it to them?  C++?  Ha.  Ha ha ha.
What happens when C++ is too low-level for the job at hand?  It's not
any more malleable than C is (though it is quite a bit more amorphous).

I've been looking for another language for a few years now, and I
don't see it.  Would you have us not write programs because there's
no good language to write them in?

Claiming that the language designer will correctly anticipate the
exact level of abstraction required for your huge program is ridiculous.
The programmer has to be able to build up abstractions as necessary.
And you can do this in C as well as you can in any of the other languages
commonly used for systems programming.

The only language that facilitates programmer-based extension
outstandingly well is Lisp, but Lisp has other problems.

Russ

Re: [9fans] same functions everywhere

[Dan Cross]

> I have the opposite opinion.  I took a substantial
> chunk of code from BRL's MUVES project, which was
> very careful to "unwind" partial operations upon
> errors, and rewrote it using a C exception package.
> The result was cleaner looking, easier to follow,
> and somewhat smaller, with explicit gotos (necessary
> to unwind nested operations) removed.  That is a win.

Sounds like a good candidate for writing in C++ or a similar language.
C isn't optimal for writing really big applications; it's great for
smaller things like utilities, text editors, systems software, etc.
But it's frankly inconvenient for building huge programs.  It's just
too low-level.  E.g., if I ever have to write another hashing function
to try and implement some sort of string-based lookup again, I'll
scream.

I don't understand why everyone feels the need to try and shoehorn
their favorite language into every conceivable problem domain.  C
doesn't need a low-level string type, nor does it need exceptions; what
programmers who are looking for those things need to do is look for
another language.

	- Dan C.

Re: [9fans] same functions everywhere

[rog]

> A better example is when a write fails.  One common reason is a full disk;
> another is a broken pipe.  They're not handled the same, but maybe they
> would have been if C had had an exception system.

a closed pipe is a special case because it is known that a write can
never work again.  (actually, i always thought you got a least one
error before you got a signal, so that a program that actually checks
for write errors won't be killed, but a quick experiment shows me to
be wrong).

writes fail all the time in plan 9, without necessarily meaning
anything unduly significant (a syntax error in a ctl request for
example).  killing the process responsible seems a bit heavy handed.

i guess one has to ask:

	would killing the process result in more sensible default
	behaviour in most cases than just ignoring the error?

in the case of named pipes, i think it's safe to say that it would.
(stopping endless resource hogging).
for most other things, i don't think so...

Re: [9fans] same functions everywhere

[rog]

> the plan9 setjmp/longjmps i've seen play with the PC and the SP.
> that's cheap.  that's why we the error stuff in the kernel doesn't
> hit performance.

if the plan 9 compilers were callee-save, it wouldn't
be so cheap, presumably.

i imagine that might be a source of the inefficiency on other
platforms.

Re: [9fans] same functions everywhere

[rog]

DAGwyn@null.net:
> rog@vitanuova.com wrote:
> > (BTW, getc doesn't use in-band signalling, and even if it did,
> > tuples are a much cleaner solution than exceptions, IMHO).
>
> In C, it certainly does.  EOF is returned instead of data
> when end-of-file is detected.

depends on how you look at the return value of getc.  there's no
ambiguity between the different kinds of return value.  one can
consider the return value from getc to be "character X or no
character" in just the same way that a function returning a pointer to
a struct can be considered to return "pointer to struct or nil".

it's a perfectly good kind of data - EOF is only out of band if one
doesn't consider "not EOF" to be part of the normal getc return value.

Re: [9fans] same functions everywhere

[Bruce Ellis]

the plan9 setjmp/longjmps i've seen play with the PC and the SP.
that's cheap.  that's why we the error stuff in the kernel doesn't
hit performance.

> For Standard C at present we seem to be limited to using
> setjmp/longjmp, which has too much overhead on most
> platforms.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

northern snowfall wrote:
>> You're all nuts.
> I call cashews

Gesundheits.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

Lucio De Re wrote:
> 	while (x < 100 && a[x] != v) {

Of course there is a well-known "kludge" when the array
has been allocated with an extra slot that can be safely
written:
	a[100] = v;	// sentinel
	while (a[x] != v) {
which speeds the loop up.  The obvious test at the end
distinguishes between "found" and "not found".

I'm not suggesting fine-grained exceptions for such
application unless tightly integrated into the language.
For Standard C at present we seem to be limited to using
setjmp/longjmp, which has too much overhead on most
platforms.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

northern snowfall wrote:
> Exceptions in a C environment is basically admitting that you
> don't understand enough about C to promote elegant and simple
> solutions to complex problems in that language.

Not really.  Exceptions reflect complications due to
some warts of the real world.  These can *occur* no
matter what syntax is available, and the only real
issue is how to deal with them.  Leaving that decision
to each and every instance of a function invocation
hardly qualifies as "elegant", and the resulting code
is not "simple" (unless it fails to deal with the
exceptional cases; alas, a lot of existing code is
like that).

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> (BTW, getc doesn't use in-band signalling, and even if it did,
> tuples are a much cleaner solution than exceptions, IMHO).

In C, it certainly does.  EOF is returned instead of data
when end-of-file is detected.  An alternative to using an
exception would be to separate the return into two kinds
of information instad of just one; since C doesn't have
tuples, and returning a struct makes for awkward usage,
we could use something like
	io_status new_getc(unsigned char *where);

Re: [9fans] same functions everywhere

[boyd, rounin]

From: "rob pike, esq." <rob@mightycheese.com>
> i'm not a fan of exceptions. good programming
> can trump them every time; bad exception handling
> can destroy a program.  they're an interesting idea
> but i judge them a failure.

sounds like a 'class 1 [dis]agreement' to me ...

--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] same functions everywhere

[boyd, rounin]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> Done right, the main advantages are:
>
> (a) uniform, tested error handling instead of ad-hoc
> (b) ensures reasonable default when user neglects to
> deal with the possibility of failre
> (c) no need for explicit tests of function error
> returns
>
> Basically, it's a way to impose order on chaos.

if 'done right'.  i'm not sure 'C' needs it.  error handling in 'C' is a nightmare
and most code gets it wrong.  i want 'C' to remain a powerful tool that does
_exactly_ what i tell it to do;  a Gerber Stilletto Backup knife -- the
thing is damn dangerous, but it does _exactly_ what i want it to do.

user mode code should not be written in 'C' -- choose a better tool for
the job, err limbo anyone?  'C' should only be used on embedded
systems, such as the kernel.  i can code my own exceptions trivially,
unlike some of the hideously complex and twisted maze of non
local gotos, oops exceptions, which various other 'programming languages'
get wrong.

strings are a real pain in 'C' so i wrote a library for 'infinite' strings; type
a buncha extra characters and you get no buffer overflows and when you
run out of memory the library spits an error message and calls exit(2) -- end
of story.

just obey:

    for (p = m; *p != '\0': p++) ...

i don't think it's on-line anymore and given i'm at:

    33V UE 29764
    MGRS   00890
    WGS 84

i can't check it out, but it is spinning on this local disk; a 256k bundle [which it is a
small part of] is just too big to post to the list.

give me IP (sic) or give me death ...
--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] same functions everywhere

[Scott Schwartz]

> encountering the end of a file is in no way an exceptional condition.

A better example is when a write fails.  One common reason is a full disk;
another is a broken pipe.  They're not handled the same, but maybe they
would have been if C had had an exception system.

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>Is that a long-distance call?
>
Not sure yet... ndb is still attempting to
translate the dial("tcp!cashews!wtf", nil, nil, nil)
call. I'll let you know when it connects.

>

Re: [9fans] same functions everywhere

[Scott Schwartz]

| You're all nuts.  But at least use nelem(a) in
| place of sizeof(a)/sizeof(int).

Maybe nelem should be a compiler builtin, so it can draw a syntax error
when applied to anything that has decayed to a pointer (i.e. almost
every use of an array).

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>You're all nuts.
>
I call cashews

Re: [9fans] same functions everywhere

[rog]

> > what kinds of exceptional conditions are you thinking about here?
>
> What would be considered "problems in completing the assignment".
> Typically, running out of some system resource, or a already
> created data structure is found to have an "impossible" value in
> some field, etc.

i think that sounds completely reasonable, and, despite rob's
comments, is de facto the case in many places in plan 9 (if you try to
use a nil data structure, divide by zero, etc).

IMHO there's probably a good case for extending this kind of
exception raising to other errors where most programs will be unable
to recover, the classic example being out-of-memory errors.

> The idea is that things that are expected to
> occur quite a lot should be dealt with in the main logic, since
> not taking them into account would be an essential lack of
> function, but that things that should rarely occur and are not
> of the same kind as expected results should be treated as
> exceptions.

with this, however, i have to disagree.

i believe an exception should represent a genuinely exceptional
condition, i.e.  something which one would not normally expect to
happen during the usual execution of the program.

if something occurs rarely, it's not necessarily exceptional in any
way.

> One could debate whether getc() returning EOF with ferror() returning
> false should be handled as an exception rather than as an exceptional
> value for the data, but I'm inclined to think that it should, after
> consideration of the problems that having in-band signals has caused.

this is a good example.

encountering the end of a file is in no way an exceptional condition.
in fact, for most programs, this condition occurring is a
pre-requisite for correct operation of the program!  using exceptions
for this kind of thing makes the code harder to read, which is a
cardinal sin.

in a normal program, i should never have to deal with exceptions at
all.

(BTW, getc doesn't use in-band signalling, and even if it did,
tuples are a much cleaner solution than exceptions, IMHO).

Re: [9fans] same functions everywhere

[Jack Johnson]

On Wed, May 07, 2003 at 10:47:54AM -0500, northern snowfall wrote:
> >You're all nuts.
> I call cashews

Is that a long-distance call?

-Jack

Re: [9fans] same functions everywhere

[Russ Cox]

> Don't blame C, blame the coder.

Love the sin, hate the sinner?

[lots of thread snipped]

You're all nuts.  But at least use nelem(a) in
place of sizeof(a)/sizeof(int).

Re: [9fans] same functions everywhere

[boyd, rounin]

#define nels(x)     (sizeof(x) / sizeof (x[0]))

for (p = m; p < &p[nels(m)]; p++) printf("duh\n");

Re: [9fans] same functions everywhere

[northern snowfall]

>    if(gotvalue(&a[0], sizeof(a), 0xdeadca75, &pos) == true)

Ack! Apparently I don't rule!
    "sizeof(a)" should be "sizeof(a) / sizeof(int)"
Don't ask me why I missed that. Um. Someone else
typed the email for me. Thats it.
Thanks Butler
Don

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>Okay, that seems *really* silly to me!
>
hehe
Well, the reason why I make it a seperate
function is because:
    1) unless specified otherwise we have to
        assume that the function will be used
        multiple times.
    2) if used multiple times we're actually
        minimizing instructures in the code
        segment by using a seperate function
    3) modular reusable code is easy to read,
        use, audit, test, retest, hack, recode, etc
    4) Because I rule
But, sure, your way works well, too :)
You're right about goto, too. Lots of people
are afraid of goto, but, as long as its used
wisely, it ain't nothin' but a jump. It all
breaks down to the right choice for the
given situation.
Don

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>Not really.  Mostly, one wants the location where the item was found
>(x, in my example) which your function discards.  Sometimes, one may
>want to take action if the item is not found.
>
I saw this comin' as soon as I hit the send button. Oh well.
Simply add in functionality to determine the slot of the
first false test.

#include <u.h>
#include <libc.h>

enum {
    true,
    false,
};

// returns true if all slots EQUATE to val
// returns false if all slots do NOT equate to val
// side effects: equates *pos to the first slot that tests false
int
gotvalue/*?*/(int * a, uint len, int val, uint * pos)
{
    uint ua;
    for(ua = 0; ua < len; ua++) {
        if(a[ua] != val) {
            *pos = ua;
            return false;
        }
    }
    return true;
}

int
main(int argc, char * argv[])
{
    int a[100];
    uint pos;

    // somehow "a" gets filled with values

    if(gotvalue(&a[0], sizeof(a), 0xdeadca75, &pos) == true)
        print("yay, we're true! \ n");
    else
        print("negate at slot %ud \n", pos);

    exits(0);
}

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>	int a[100];
>	int x, v;
>
>	...
>
>	x = 0;
>	while (x < 100 && a[x] != v) {
>		++x;
>	}
>
Ok, this seems pretty silly to me, because, it just
breaks down to bad coding style.

#include <u.h>
#include <libc.h>

enum {
    true,
    false,
};

// returns true if value IS found in every slot
// returns false if value is NOT found in every slot
int
gotvalue/*?*/(int * a, uint len, int val)
{
    uint xa;

    for(ua = 0; ua < len; ua++) {
        if(a[ua] != val)
            return false;
    }
    return true;
}

void
main(int argc, char * argv[])
{
    int a[100];

    // somehow "a" gets filled with values

    if(gotvalue(&a[0], sizeof(a), 0xdeadca75) == true)
        print("yay, we're true! \n");
    else
        print("ick. \n");

    exits(0);
}

Re: [9fans] same functions everywhere

[David Butler]

Okay, that seems *really* silly to me! Why make a
subroutine call? Why re-test at the end what you know?
If it can be remembered that C is really a portable
assembly language, you will program in a "structured"
assembly style. Use the language:

  int a[100];
  int x, v;

  for (x = sizeof(a) / sizeof(a[0]); x >= 0; x--) {
    if (a[x] == v) {
      goto foundv;
    }
  }

  damn;

foundv:
  cool;

:)

Goto is not bad, programmers that misuse goto are bad.

David

----- Original Message -----
From: "northern snowfall" <dbailey27@ameritech.net>
To: <9fans@cse.psu.edu>
Sent: Wednesday, May 07, 2003 8:05 AM
Subject: Re: [9fans] same functions everywhere


> >
> >
> > int a[100];
> > int x, v;
> >
> > ...
> >
> > x = 0;
> > while (x < 100 && a[x] != v) {
> > ++x;
> > }
> >
> Ok, this seems pretty silly to me, because, it just
> breaks down to bad coding style.
>
> #include <u.h>
> #include <libc.h>
>
> enum {
>     true,
>     false,
> };
>
> // returns true if value IS found in every slot
> // returns false if value is NOT found in every slot
> int
> gotvalue/*?*/(int * a, uint len, int val)
> {
>     uint xa;
>
>     for(ua = 0; ua < len; ua++) {
>         if(a[ua] != val)
>             return false;
>     }
>     return true;
> }
>
> void
> main(int argc, char * argv[])
> {
>     int a[100];
>
>     // somehow "a" gets filled with values
>
>     if(gotvalue(&a[0], sizeof(a), 0xdeadca75) == true)
>         print("yay, we're true! \n");
>     else
>         print("ick. \n");
>
>     exits(0);
> }
>
>
>

Re: [9fans] same functions everywhere

[Lucio De Re]

On Wed, May 07, 2003 at 08:05:33AM -0500, northern snowfall wrote:
> >
> Ok, this seems pretty silly to me, because, it just
> breaks down to bad coding style.
>
Not really.  Mostly, one wants the location where the item was found
(x, in my example) which your function discards.  Sometimes, one may
want to take action if the item is not found.

Was it APL that returned -1 on not found?  Doesn't help much if I'm
not interested, as I still have to check the validity of the return
value.

++L

Re: [9fans] same functions everywhere

[northern snowfall]

>
>
>>Because I think the main problem C has is buffer overruns, and I believe
>>that the main cause of that is that people use C arrays, pointers,
>>which don't encode the bounds, along with standard library routines that
>>discourage doing anything else
>>
The beauty of C is its ability to allow the programmer a very
eloquent sense of flexibility with the underlying system.
"Buffer overruns" are just the manifestation of bad programming,
not a weakness in the language, itself. Every language has its
issues, but, that's where experience and a deep understanding
of how a language works comes in handy :-)
Don't blame C, blame the coder.
Exceptions in a C environment is basically admitting that you
don't understand enough about C to promote elegant and simple
solutions to complex problems in that language. Putting the
blame on C, itself, is simplistic and, frankly, arrogant.
Don

Re: [9fans] same functions everywhere

[Lucio De Re]

On Wed, May 07, 2003 at 06:03:51AM -0500, northern snowfall wrote:

> Exceptions in a C environment is basically admitting that you
> don't understand enough about C to promote elegant and simple
> solutions to complex problems in that language. Putting the
> blame on C, itself, is simplistic and, frankly, arrogant.

I don't go along with that.  Consider the conventional linear search
of an array:

	int a[100];
	int x, v;

	...

	x = 0;
	while (x < 100 && a[x] != v) {
		++x;
	}

(or whatever version you prefer).

At the end, you always have to determine whether you found the
desired element or exceeded the array bounds.  Now, if exceeding
the array bounds could be treated as an exception (imagine a clever
CPU with array bounds checking in hardware delivering a segment
violation error), you could write:

	x = 0;
	while (a[x] != v) {
		++x;
	}

and at the end you'd know that the element was found, because the
exception wasn't triggered.  Better, you'd not even reach the end
of the loop if the element wasn't found.

This particular problem has bugged me for decades :-)  I go along
with Doug that exception handling can hide the extremely uninteresting
code involved in dealing with rare or "off band" conditions.

++L

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> what kinds of exceptional conditions are you thinking about here?

What would be considered "problems in completing the assignment".
Typically, running out of some system resource, or a already
created data structure is found to have an "impossible" value in
some field, etc.  The idea is that things that are expected to
occur quite a lot should be dealt with in the main logic, since
not taking them into account would be an essential lack of
function, but that things that should rarely occur and are not
of the same kind as expected results should be treated as
exceptions.  Looking at it another way, if it seems that a
situation should be handled within an ongoing loop then it's
not a candidate for an exception, but if it seems that the loop
needs to be aborted because it would be pointless to continue
in the same vein, then it should be an exception.  Yet another
take on the same thing:  If local tactics are expected then it's
not a candidate for an exception, but if a global strategy for
recovery from the condition is expected, then it's an exception.
In practice, the distinction is usually clear.  One could debate
whether getc() returning EOF with ferror() returning false should
be handled as an exception rather than as an exceptional value
for the data, but I'm inclined to think that it should, after
consideration of the problems that having in-band signals has
caused.

Re: [9fans] same functions everywhere

[boyd, rounin]

----- Original Message -----
From: "Scott Schwartz" <schwartz@bio.cse.psu.edu>
> Because I think the main problem C has is buffer overruns, and I believe
> that the main cause of that is that people use C arrays, pointers,
> which don't encode the bounds, along with standard library routines that
> discourage doing anything else.

nope, use a better tool; limbo -- leave 'C' alone.

Re: [9fans] same functions everywhere

[Boyd Roberts]

> Doug is thinking ahead to C1x.

i hope the lessons of python style exception handling have been learned.

--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] same functions everywhere

[Boyd Roberts]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> It's much, much easier when the library functions throw
> exceptions.  That way the application can handle them any
> way it wants (or allow default handling to occur, normally
> a fatal error), and the same utility library can be used
> unchanged with any application.

hmm, exceptions can be a nightmare, if they turn out to be
a 'nasty set of  nested non local gotos' -- ouch.

but if they're done 'right', then ok ...

--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] same functions everywhere

[rog]

> If you're going to handle errors, the code has to exist one way or
> another.  A good exception facility centralizes the error handling in
> a corner away from the main logic.  Error handling inherently
> interferes with the main logic; it is easier to verify loop invariants
> etc.  if one doesn't have the "error terms" in the assertions.
> Usually the corner with the error handling can be verified as doing
> the correct thing much more simply than if the possible error cases
> are scattered through the main logic.

what kinds of exceptional conditions are you thinking about here?

Re: [9fans] same functions everywhere

[Joel Salomon]

"Douglas A. Gwyn" <DAGwyn@null.net> wrote:

> The main improvement is that the main logic is much more visible, since
> there is no clutter from testing for all those things that are
> incidental to the intended function of the components

Except in java, where *everything* (almost) that can be thrown must be
checked for. Good thing that port was stopped.

Fortunately, I don't think that Java's idiocy can be imposed by any C
based exception package.

Just my $.02

--Joel

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rob pike, esq. wrote:
>>(a) uniform, tested error handling instead of ad-hoc
> only for certain kinds of errors. you still need to write explicit
> code (perhaps using exceptions) for many kinds of errors.

The point is that the same mechanism is used everywhere.
Of course when the current higher-level handling strategy
is not what is wanted in a specific situation, one has to
provide an implementation of whatever strategy is wanted
for that situation.  That strategy can take advantage of
the more global one to field exceptions that the local
code doesn't know how to handle.

>>(b) ensures reasonable default when user neglects to
>>deal with the possibility of failre
> a weak premise and again, only for certain errors.

The current handler for the thrown exception class
fields whatever exceptions the local code doesn't know
about.  Or, the local code could handle the unknown
exception classes if it really wants total control.
The programmer gets to decide, but in the (all too
frequent) case where he hasn't anticipated a failure,
at least the next higher level does whatever it deemed
appropriate, which is generally better than proceeding
to compute "at random" with bogus data.

>>(c) no need for explicit tests of function error
>>returns
> therefore subverting programming discipline.

It's just a different form of discipline.  The main
improvement is that the main logic is much more
visible, since there is no clutter from testing for
all those things that are incidental to the intended
function of the components.  I.e. malloc's job is to
allocate a chunk of storage, not really to test
whether the program has run out of heap space.  The
latter hopefully never occurs, so almost all the time
those tests are for naught.  I'm sure we have all
seen lots of code where the programmer doesn't bother
to check for a null return from malloc, which he has
(good but not perfect) reason to think will not occur.
Such a programmer is a happier one, and with exception
handling in place running out of heap gets caught and
reported without bothering the programmer at all.

>>Basically, it's a way to impose order on chaos.
> and replace it with a mysterious, hard to understand
> mechanism with a tendency to overlay a program's
> structure with confusing, noisy error-handling
> details.

If you're going to handle errors, the code has to
exist one way or another.  A good exception facility
centralizes the error handling in a corner away from
the main logic.  Error handling inherently interferes
with the main logic; it is easier to verify loop
invariants etc. if one doesn't have the "error terms"
in the assertions.  Usually the corner with the error
handling can be verified as doing the correct thing
much more simply than if the possible error cases are
scattered through the main logic.

> i'm not a fan of exceptions. good programming
> can trump them every time; bad exception handling
> can destroy a program.  they're an interesting idea
> but i judge them a failure.

I have the opposite opinion.  I took a substantial
chunk of code from BRL's MUVES project, which was
very careful to "unwind" partial operations upon
errors, and rewrote it using a C exception package.
The result was cleaner looking, easier to follow,
and somewhat smaller, with explicit gotos (necessary
to unwind nested operations) removed.  That is a win.

Re: [9fans] same functions everywhere

[Andrew Simmons]

Re exceptions, I found the following quote from Stroustrup interesting:

"A notable exception to this agreement was Doug McIlroy, who stated that the
availability of exception handling would make systems less reliable because
library writers and other programmers will throw exceptions rather than try
to understand and handle problems. Only time will tell to what extent Doug's
prediction will be true."

Re: [9fans] same functions everywhere

[rob pike, esq.]

> (a) uniform, tested error handling instead of ad-hoc

only for certain kinds of errors. you still need to write explicit
code (perhaps using exceptions) for many kinds of errors.

> (b) ensures reasonable default when user neglects to
> deal with the possibility of failre

a weak premise and again, only for certain errors.

> (c) no need for explicit tests of function error
> returns

therefore subverting programming discipline.

> Basically, it's a way to impose order on chaos.

and replace it with a mysterious, hard to understand
mechanism with a tendency to overlay a program's
structure with confusing, noisy error-handling
details.

i'm not a fan of exceptions. good programming
can trump them every time; bad exception handling
can destroy a program.  they're an interesting idea
but i judge them a failure.

-rob

Re: [9fans] same functions everywhere

[FJ Ballesteros]

Yes. I think one of the programs in sources /nemo includes a
util.[ch] that has one of such packages.

Joel Salomon wrote:

> On Thu, 1 May 2003, Russ Cox wrote:
>
>>You're preaching to the choir.  Look at the Plan 9 kernel.
>>
>
> So can the kernel's "exceptions" be packaged in library form for
> applications?
>
> --Joel
>
>

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rsc@plan9.bell-labs.com wrote:
> Given the syntactic weight of C exception
> ``libraries'', I'm not convinced they're appropriate
> for things like fopen failing.  I think it would be
> of limited use.  The code itself is utterly trivial.

Done right, the main advantages are:

(a) uniform, tested error handling instead of ad-hoc
(b) ensures reasonable default when user neglects to
deal with the possibility of failre
(c) no need for explicit tests of function error
returns

Basically, it's a way to impose order on chaos.

Re: [9fans] same functions everywhere

[Taj Khattra]

On Thu, May 01, 2003 at 01:21:19PM -0400, rsc@plan9.bell-labs.com wrote:
> There are some programs that use the same method,
> but it's best used in moderation.

e.g. squint, rob's Newsqueak interpreter

-taj

Re: [9fans] same functions everywhere

[rsc]

Given the syntactic weight of C exception
``libraries'', I'm not convinced they're appropriate
for things like fopen failing.  I think it would be
of limited use.  The code itself is utterly trivial.

Re: [9fans] same functions everywhere

[Joel Salomon]

On Thu, 1 May 2003 rsc@plan9.bell-labs.com wrote:
> There are some programs that use the same method,
> but it's best used in moderation.  I haven't seen many
> programs that would really benefit from it.

So someone porting one of the C "exception" libraries would be a bad idea,
or just of limited use? (Assuming the implementation would come with
wrappers for malloc, fopen, etc.)

--Joel

Re: [9fans] same functions everywhere

[rsc]

There are some programs that use the same method,
but it's best used in moderation.  I haven't seen many
programs that would really benefit from it.  (Except, of
course, user-level ports of the Plan 9 kernel.)

Re: [9fans] same functions everywhere

[Joel Salomon]

On Thu, 1 May 2003, Russ Cox wrote:
>
> You're preaching to the choir.  Look at the Plan 9 kernel.

So can the kernel's "exceptions" be packaged in library form for
applications?

--Joel

Re: [9fans] same functions everywhere

[Scott Schwartz]

| Scott Schwartz wrote:
| > | > Can Plan 9 libraries throw such exceptions? where does this functionality
| > | > exist?
| > | Doug is thinking ahead to C1x.
| > Tell Doug that the committee should be thinking about a standard counted
| > string/array mechanism instead.
|
| Why?

Because I think the main problem C has is buffer overruns, and I believe
that the main cause of that is that people use C arrays, pointers,
which don't encode the bounds, along with standard library routines that
discourage doing anything else.

My hypothesis is that if there were an official string library then
people would use that and have fewer bugs, especially if there were a
little syntactic sugar.

	int array q;

Re: [9fans] same functions everywhere

[Russ Cox]

> Actally, no.  Several people (including me) have implemented
> general, low-overhead exception-handling systems in C.  It
> would be possible to make them more convenient with support
> in the language itself, but one can go a long way just by
> exploiting setjmp/longjmp via better packaging.

You're preaching to the choir.  Look at the Plan 9 kernel.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

rsc@plan9.bell-labs.com wrote:
>>Can Plan 9 libraries throw such exceptions? where does this functionality
>>exist?
> Doug is thinking ahead to C1x.

Actally, no.  Several people (including me) have implemented
general, low-overhead exception-handling systems in C.  It
would be possible to make them more convenient with support
in the language itself, but one can go a long way just by
exploiting setjmp/longjmp via better packaging.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

Scott Schwartz wrote:
> | > Can Plan 9 libraries throw such exceptions? where does this functionality
> | > exist?
> | Doug is thinking ahead to C1x.
> Tell Doug that the committee should be thinking about a standard counted
> string/array mechanism instead.

Why?

Re: [9fans] same functions everywhere

[Scott Schwartz]

| > Can Plan 9 libraries throw such exceptions? where does this functionality
| > exist?
|
| Doug is thinking ahead to C1x.

Tell Doug that the committee should be thinking about a standard counted
string/array mechanism instead.

Re: [9fans] same functions everywhere

[rsc]

> Can Plan 9 libraries throw such exceptions? where does this functionality
> exist?

Doug is thinking ahead to C1x.

Re: [9fans] same functions everywhere

[Joel Salomon]

On Wed, 30 Apr 2003, Douglas A. Gwyn wrote:
>
> It's much, much easier when the library functions throw
> exceptions.  That way the application can handle them any
> way it wants (or allow default handling to occur, normally
> a fatal error), and the same utility library can be used
> unchanged with any application.
>
Can Plan 9 libraries throw such exceptions? where does this functionality
exist?

--Joel

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

"Fco.J.Ballesteros" wrote:
> I agree that each application should be able to do whatever it wants,
> and also that probably this code shouldnt get in the library by default;
> but I'd like to see several alternate libraries for error handling so that
> when I write an application (and not a library) I could borrow them.

It's much, much easier when the library functions throw
exceptions.  That way the application can handle them any
way it wants (or allow default handling to occur, normally
a fatal error), and the same utility library can be used
unchanged with any application.

Re: [9fans] same functions everywhere

[Boyd Roberts]

> > Gorka
> > ゴルカ
>
> It's correct!

yup, go ru ka

Re: [9fans] same functions everywhere

[Boyd Roberts]

----- Original Message -----
From: <paurea@plan9.escet.urjc.es>
> Most of them do exactly the same, calling sysfatal.  The only
> different thing is the error string and sometimes, it is just "out of
> memory" or variations on this.

yup, you got that right.

then again, there is limbo and memory is 'free'.

Re: [9fans] same functions everywhere

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

I just think that for whatever mechanism you want, if it's
commonly used we could just put it in a library intended for
the final application (and not for other library implementors, despite
being bizarre). Actually, I kind of do that; most of the silly apps
I write use a tiny utils.[ch] package that includes among other things
emalloc, errealloc, catcherror, noerror and error (exceptions along the
lines of the exception handling code in the kernel).

I agree that each application should be able to do whatever it wants,
and also that probably this code shouldnt get in the library by default;
but I'd like to see several alternate libraries for error handling so that
when I write an application (and not a library) I could borrow them.

[-- Attachment #2: Type: message/rfc822, Size: 1838 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
Date: Fri, 25 Apr 2003 10:40:40 GMT
Message-ID: <3EA6EADB.16078459@null.net>

paurea@plan9.escet.urjc.es wrote:
> On another terms, it would be great to have some function, macro, mechanism
> or whatever to describe calling a function and calling sysfatal on error, because
> this usage of functions repeats itself a lot.

I would suggest instead installing a general exception package,
with a global handler to field uncaught exceptions; the global
handler could call sysfatal.

Re: [9fans] same functions everywhere

[David Presotto]

Yup.  We have fsetpos and fgetpos in addition to fsicko, ah fseeko
and ftello.  Only did it because the ape library exists to port
posix compliant programs.  I was torn about changing it in the plan9
non-ape stdio but did that one too in the hope that our programs will
port out more easily.  I was probably being silly.

Re: [9fans] same functions everywhere

[Douglas A. Gwyn]

paurea@plan9.escet.urjc.es wrote:
> On another terms, it would be great to have some function, macro, mechanism
> or whatever to describe calling a function and calling sysfatal on error, because
> this usage of functions repeats itself a lot.

I would suggest instead installing a general exception package,
with a global handler to field uncaught exceptions; the global
handler could call sysfatal.

Re: [9fans] same functions everywhere

[Sam]

>
> grep '[^e]mallocz' `{du -a /sys/src | awk '{print $2}' | grep '\.c$'}
> | wc -l
>     149

My apologies, this should read:

grep '[^e]mallocz(.*,.*)' `{du -a /sys/src | awk '{print $2}' | grep
'\.c$'} | wc -l
	149

or else you pick up the mallocz versions redefined by others who
have elided the second argument.  The number is still correct - I
flub'd transcribing.

Sam

Re: [9fans] same functions everywhere

[Sam]

>
> Most of them do exactly the same, calling sysfatal.  The only
> different thing is the error string and sometimes, it is just "out of
> memory" or variations on this.
>

Is the argument purely about ambiguity?  I don't see anything
about the name emalloc(...) that indicates it will take the program
down.  This is less of an issue in a program context as the scope
is generally tighter (and the programmer wrote it).

Perhaps if the name were changed to fatalmalloc and you could
pass in a string for sysfatal it would be less ambiguous.  It
just seems like a moot point for 6 lines of code.

If you want to pick on malloc, why not lambast mallocz for having
the second parameter to qualify the zero'ing?  Its primary use
is for dynamically discerning whether to zero out the associated
memory, and in

grep '[^e]mallocz' `{du -a /sys/src | awk '{print $2}' | grep '\.c$'}
| wc -l
    149

149 uses there isn't one call that does this.

Sam

Re: [9fans] same functions everywhere

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 116 bytes --]

sam and acme, for instance, have a good attempt at
saving work-in-progress, and arguably a few others should too.

[-- Attachment #2: Type: message/rfc822, Size: 1872 bytes --]

From: paurea@plan9.escet.urjc.es
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
Date: Thu, 24 Apr 2003 14:02:58 +0200
Message-ID: <5258fb01cfa482d7b8d985e1c26dfac1@plan9.escet.urjc.es>


> The argument I think carries the day is that error handling is an
> application-specific issue, not a library issue.  I have written emalloc
> several times but each application tends to do something different
> in the error case.  That is the real point.
>


Most of them do exactly the same, calling sysfatal.  The only
different thing is the error string and sometimes, it is just "out of
memory" or variations on this.



							Gorka

Re: [9fans] same functions everywhere

[paurea]

> The argument I think carries the day is that error handling is an
> application-specific issue, not a library issue.  I have written emalloc
> several times but each application tends to do something different
> in the error case.  That is the real point.
>


Most of them do exactly the same, calling sysfatal.  The only
different thing is the error string and sometimes, it is just "out of
memory" or variations on this.



							Gorka

Re: [9fans] same functions everywhere

[okamoto]

> 							Gorka
> ゴルカ

It's correct!

Kenji

Re: [9fans] same functions everywhere

[rob pike, esq.]

> An intermediate way would be to add another library with
> common tools like those ones. But maybe we end up with too many
> libraries then...

This doesn't really address the objection unless you also require that
other libraries not use this one, which seems bizarre.

The argument I think carries the day is that error handling is an
application-specific issue, not a library issue.  I have written emalloc
several times but each application tends to do something different
in the error case.  That is the real point.

-rob

Re: [9fans] same functions everywhere

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

An intermediate way would be to add another library with
common tools like those ones. But maybe we end up with too many
libraries then...

[-- Attachment #2: Type: message/rfc822, Size: 1884 bytes --]

From: paurea@plan9.escet.urjc.es
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
Date: Wed, 23 Apr 2003 17:29:08 +0200
Message-ID: <e40276308b5dbec193161e2129556275@plan9.escet.urjc.es>

> The problem is that if they are in the library
> then it encourages other libraries to use
> them, and then we end up with a C library
> in which it is impossible to correctly handle
> an out-of-memory error.

I see the point, but can't swallow they have to be reimplemented so
many times.

>
> The decision to abort is best left up to the
> application.

I agree that the decision is best left up to the application, but
having to rewrite or copy the implementation of the funtcions
everywhere shouldn't be necessary.  I feel this is not the Right thing
to do.  The only alternatives I can think of are ugly patches, so if
you have any idea...


							Gorka
ゴルカ

Re: [9fans] same functions everywhere

[paurea]

> The problem is that if they are in the library
> then it encourages other libraries to use
> them, and then we end up with a C library
> in which it is impossible to correctly handle
> an out-of-memory error.

I see the point, but can't swallow they have to be reimplemented so
many times.

>
> The decision to abort is best left up to the
> application.

I agree that the decision is best left up to the application, but
having to rewrite or copy the implementation of the funtcions
everywhere shouldn't be necessary.  I feel this is not the Right thing
to do.  The only alternatives I can think of are ugly patches, so if
you have any idea...


							Gorka
ゴルカ

Re: [9fans] same functions everywhere

[Russ Cox]

> Reading the code for different commands and filesystems, I have found
> there are at least three functions repeated with equivalent
> implementations all over the place. These are erealloc emalloc and estrdup.
> They call the function without the e and call sysfatal on error. Wouldn't it
> be more economical and clear to have them on a library?.

I almost did this but was talked out of it.
The problem is that if they are in the library
then it encourages other libraries to use
them, and then we end up with a C library
in which it is impossible to correctly handle
an out-of-memory error.

The decision to abort is best left up to the
application.

[9fans] same functions everywhere

[paurea]

Reading the code for different commands and filesystems, I have found
there are at least three functions repeated with equivalent
implementations all over the place. These are erealloc emalloc and estrdup.
They call the function without the e and call sysfatal on error. Wouldn't it
be more economical and clear to have them on a library?.

On another terms, it would be great to have some function, macro, mechanism
or whatever to describe calling a function and calling sysfatal on error, because
this usage of functions repeats itself a lot.



									Gorka