rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* Re: RC => POSIX
@ 1997-03-06 17:15 Alan Watson
  1997-03-06 17:54 ` Scott Schwartz
  0 siblings, 1 reply; 20+ messages in thread
From: Alan Watson @ 1997-03-06 17:15 UTC (permalink / raw)
  To: rc

> >Agreed, "all the old BSD and SysV systems" would fall behind. 
> [...]
> 
> [...]
> There's a lot of old iron out there doing useful work.  Ask Byron, I'm
> sure he had a lot of mail from folks with strange incompatibilities.

Lets stop and look at where we are.

The behaviour of rc is, for all intents and purposes, fixed. We are
talking about rc-1.5 not because we want new features or want bugs
fixed, but because we want rc-1.4 to work on new iron. Presumably,
those people with old iron can continue to run rc-1.4.

Making rc-1.5 run on just POSIX systems would make it significantly
easier to maintain. Given the resources that are available, this is a
very worthy goal.

(On a related note, separating rc from readline would make it
significantly easier to maintain, but lets not get into that one
again.)

Alan


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
  1997-03-06 17:15 RC => POSIX Alan Watson
@ 1997-03-06 17:54 ` Scott Schwartz
  0 siblings, 0 replies; 20+ messages in thread
From: Scott Schwartz @ 1997-03-06 17:54 UTC (permalink / raw)
  To: Alan Watson; +Cc: rc

Alan Watson <alan@oldp.nmsu.edu> writes:
| The behaviour of rc is, for all intents and purposes, fixed. We are
| talking about rc-1.5 not because we want new features or want bugs
| fixed, but because we want rc-1.4 to work on new iron. Presumably,
| those people with old iron can continue to run rc-1.4.

On the contrary.  If you just ignore all the posix inventions you can
still compile and run Unix programs, because posix systems always
include compatability features.  For example, there's no need for
sigaction, because signal does the right thing.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-29 20:23 Bengt Kleberg
  0 siblings, 0 replies; 20+ messages in thread
From: Bengt Kleberg @ 1997-03-29 20:23 UTC (permalink / raw)
  To: Uhl, rc; +Cc: uhl

> I'd like to vote in favour of modifying rc's code for Posix compatibility.
Shouldn't we first decide if we should vote? And if so, how should we vote?
For instance, I think that Byron should have atleast as many votes as every
body else combined (only half joking :-)

But, yes, I still think POSIX is a good idea.

Bengt


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-27  9:58 Malte Uhl
  0 siblings, 0 replies; 20+ messages in thread
From: Malte Uhl @ 1997-03-27  9:58 UTC (permalink / raw)
  To: rc; +Cc: uhl

Fellow rc'ers,

I'd like to vote in favour of modifying rc's code for Posix compatibility. 
Not because Posix (and XOPEN for that matter) compatibility is a good thing 
in itself, but because Posix provides a standard way to avoid BSD'isms and 
SysV'isms. Even Windows NT claims to be Posix conformant. Conforming to Posix 
and XOPEN standards does reduce porting efforts! This is from personal 
experience.

But how many systems are there not supporting these standards? Well, few 
compared to the number of up to date or recently upgraded systems (let's say 
no older than 3 years). Even the GNU C library, Linus, NetBSD and Minix claim 
to be compatible. On those systems not compatible one can choose to run the 
1.5 version, or alternatively install their own Posix compatibility library.

Now, let me comment on the claims that K&R C + lint is more portable that 
ANSI C:

First of all, one has to redo the lint checking on every (new) system. If 
lint does find problems, one will have to redo the neccessary changes, too, 
leaving asize the fact that some people will not be able to do this because 
of a lack of knowledge. Alternatively, lint checking can be done once for 
every supported system, but then there'll be quite a few #ifdef's. Given lint 
does not find (m)any problems, I postulate it could have been coded in ANSI C 
as well.

Secondly, even if all my above ranting were false, I wonder why Ansi C + lint 
should be inferior. Also note, that ANSI C standardizes some part of the C 
library.

Thirdly, the problem with K&R vs. ANSI declarations has long been solved by 
the GNU ansidecl.h header. Well, ok, not solved but alleviated.

About GNU autoconf, let me say that I it's a bitter-sweet thing. For those 
who do not know, it's a feature test facility, generating C header files for 
a particular system from an abstract specification made by the developer of 
the software. It's sweet because it does it's job very well. But it's bitter 
because it doesn't check for groups of features, but each one on its own, 
e.g. it does not test if a system is ANSI C/Posix compatible and then 
configures the software to use all the Posix features, but tests every 
feature required independantly of the others. If, as a programmer, you should 
choose to use poll and select, autoconf will check both features and allow 
you to use both if available, although there's no point in doing so. In my 
opinion autoconf should configure the software to use either a native API or 
a standard API but not allow features to be mixed up. There should at least 
be a warning in this case.

And now for those who are still reading, I know that Posix is not a single 
fixed standard, covering all fields of system programming. But it does offer 
some very useful features, such as signal semantics which is a well thought 
out generalization of BSD and SysV style and it offers standard access to 
several timer functions and job control, too. To me, this is reason enough to 
stick to Posix/XOPEN wherever possible.

Malte



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
  1997-03-26 11:54 Byron Rakitzis
@ 1997-03-26 16:45 ` Greg A. Woods
  0 siblings, 0 replies; 20+ messages in thread
From: Greg A. Woods @ 1997-03-26 16:45 UTC (permalink / raw)
  To: Byron Rakitzis; +Cc: rc

[ On Wed, March 26, 1997 at 03:54:26 (PST), Byron Rakitzis wrote: ]
> Subject: Re: RC => POSIX
>
> Would all such new unices support posix?

Most are close, but not that many are officially branded (or even tested).

> Does gnu autoconf effectively
> cover the entire space of unices?

All that I've encountered though I have not tried running it on
something like SysVr2 or even SysVr3.  Of course autoconf is extensible
if necessary, and will no doubt be fixed as incompatabilities appear
too.

The latest version of autoconf generated configure scripts are known to
fail on some ancient versions of sh, but I've found that all such
systems with broken /bin/sh's also have newer shells, such as ksh,
installed by default, so it's trivial for the user to work around such
problems.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
  1997-03-26  8:33 Bengt Kleberg
@ 1997-03-26 16:38 ` Greg A. Woods
  0 siblings, 0 replies; 20+ messages in thread
From: Greg A. Woods @ 1997-03-26 16:38 UTC (permalink / raw)
  To: rc

[ On Wed, March 26, 1997 at 09:33:04 (+0100), Bengt Kleberg wrote: ]
> Subject: Re: RC => POSIX
>
> I interpreted Mr Rakitzis previous message as a suggestion that ANSI
> function prototypes should go, since K&R C is more portable (available
> on more systems).

The problem is that while prototypes help catch parameter mismatches,
they must be used with strict new-style function definition syntax,
esp. with some less lax ANSI compilers (this is due to incompatabilities
invoving type promotion in expressions between ANSI C and K&R C).  As a
result the code gets very messy if you try to #ifdef both styles.

Indeed pure K&R C is still far more portable, and with careful use of
lint, still safer (in the sense that more function call problems can be
prevented) than most ANSI compilers are today.

Where I'm getting at here is that the most portable style of C coding is
probably to use ANSI definitions and prototypes exclusively, and rely on
some tool such as unproto or ansi2knr to automatically support older
compilers.  BTW, I've had far better luck with unproto, and it doesn't
require any makefile magic if it's installed properly on the target
system, though ansi2knr (from the GNU automake distribution) is easier
to use since you ship it with the package and automake does all the
"right" things to build portable makefiles for using it.

This of course necessitates still running lint occasionally with k&r
type promotion checking turned on and inserting all casts necessary for
k&r in function calls.  This is probably what would be best for rc since
most of the developers are likely to use ANSI C compilers and thus can
benefit immeadiately from prototype checking even if they don't have a
working lint implementation in their enironments.

Personally I detest ANSI function definition syntax (it is difficult to
read and very inelegant), and so I stick to straight k&r C in my own
code and rely on lint for more complex syntax checking.  Prototypes can
even work if you're using an ANSI compiler that can be told to always
follow k&r type promotion (eg. GCC).

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-26 11:54 Byron Rakitzis
  1997-03-26 16:45 ` Greg A. Woods
  0 siblings, 1 reply; 20+ messages in thread
From: Byron Rakitzis @ 1997-03-26 11:54 UTC (permalink / raw)
  To: Bengt.Kleberg, byron, woods; +Cc: rc

Hey, you don't have to switch to my last name! I hope my last
message was not taken in the wrong light. I was just trying to
clarify my previous words.

I don't think prototyped code should go. ANSI compilers are
practically ubiquitous, and there are filters for converting code
to the old style.  Early on, in 1991 maybe, I seem to remember
someone going through this exercise.

I think it would help to clearly define what the goal is of changing
the style with which rc is now coded. I would like to remain
compatible with whatever machines out there right now happily
compile and run rc, and I would also like to make it possible for
rc to be easily ported to a unix that isn't predefined in config.h.

Would all such new unices support posix? Does gnu autoconf effectively
cover the entire space of unices?

Byron.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-26  8:33 Bengt Kleberg
  1997-03-26 16:38 ` Greg A. Woods
  0 siblings, 1 reply; 20+ messages in thread
From: Bengt Kleberg @ 1997-03-26  8:33 UTC (permalink / raw)
  To: woods, byron; +Cc: rc

> >Byron has written that it is better to be portable than POSIX. He even
> >mentioned ANSI C as a stumbeling block for portablility. To be
> >consequent I therefore suggest that ANSI C is dropped (or POSIX adopted :-)
> 
> I'm not sure what you are saying here. I think I mentioned that
> the fake ansi headers that rc ships are an obstacle to portability.
> That doesn't have much to do with ansi C.
> 

I apologise for any confusion (especially if my email, by mistake, can
be considered negative towards Mr Rakitzis).

I interpreted Mr Rakitzis previous message as a suggestion that ANSI
function prototypes should go, since K&R C is more portable (available
on more systems).

Best Wishes, Bengt
--------------------------------------------------------------------
New Email => bengtk@damek.kth.se
Disclaimer: As far as I know the abovementioned opinions where only mine.
``At the moment money does indeed make the world go round but unfortunately
  the direction of that applied rotation is all downhill.'' fleecy@netreach.net
  


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-25 22:30 Byron Rakitzis
  0 siblings, 0 replies; 20+ messages in thread
From: Byron Rakitzis @ 1997-03-25 22:30 UTC (permalink / raw)
  To: Bengt.Kleberg, woods; +Cc: rc

>Byron has written that it is better to be portable than POSIX. He even
>mentioned ANSI C as a stumbeling block for portablility. To be
>consequent I therefore suggest that ANSI C is dropped (or POSIX adopted :-)

I'm not sure what you are saying here. I think I mentioned that
the fake ansi headers that rc ships are an obstacle to portability.
That doesn't have much to do with ansi C.

I think I would like to clean up the source so that it compiles
with an ANSI compiler, but omit the home-grown system prototypes
and typedefs.  Perhaps such home-grown prototypes anticipate
portability problems (e.g., having size_t be signed as on SunOS 4
could imply any number of bugs if the code assumes unsigned), but
I am not sure.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
  1997-03-24  9:18 Bengt Kleberg
@ 1997-03-24 20:22 ` Greg A. Woods
  0 siblings, 0 replies; 20+ messages in thread
From: Greg A. Woods @ 1997-03-24 20:22 UTC (permalink / raw)
  To: Bengt Kleberg; +Cc: rc

[ On Mon, March 24, 1997 at 10:18:15 (+0100), Bengt Kleberg wrote: ]
> Subject: Re: RC => POSIX
>
> This is what I don't like. When it comes to programming I prefer restrictions.

Perhaps you're not aware of just how restrictive POSIX programming must
be.  Where it's not restricted things are left completely un-defined.
At least with the general GNU coding all variants of systems can be
taken into account and all features of systems can be used.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-24  9:18 Bengt Kleberg
  1997-03-24 20:22 ` Greg A. Woods
  0 siblings, 1 reply; 20+ messages in thread
From: Bengt Kleberg @ 1997-03-24  9:18 UTC (permalink / raw)
  To: woods; +Cc: rc

...deleted
> It would be far more productive and result in a far more portable
> product to integrate GNU Autoconf et al and didn't I just see a note
> about es being autoconf'ed pass by here earlier?  Taking the autoconf
> support from es should be trivial, esp. to any rc-internals programmer
> with any experience using autoconf.
> 

Byron has written that it is better to be portable than POSIX. He even
mentioned ANSI C as a stumbeling block for portablility. To be
consequent I therefore suggest that ANSI C is dropped (or POSIX adopted :-)

> The GNU Autoconf philosophy is similar in some ways to what you suggest,
> esp. in that autoconf'ed packages usually provide a compatability
> library for those system functions the software uses but which are not
> always available on all systems.  However the autoconf style isn't
> anywhere nearly so restrictive as porting directly to plain POSIX would
> be.

This is what I don't like. When it comes to programming I prefer restrictions.

...deleted

Best Wishes, Bengt
--------------------------------------------------------------------
Email: Bengt.Kleberg@enea.se (Enea Data AB, Sweden)
Disclaimer: Nothing abovementioned has any connection to Enea Data AB
``At the moment money does indeed make the world go round but unfortunately
  the direction of that applied rotation is all downhill.'' fleecy@netreach.net


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-08  0:13 Byron Rakitzis
  0 siblings, 0 replies; 20+ messages in thread
From: Byron Rakitzis @ 1997-03-08  0:13 UTC (permalink / raw)
  To: Uhl, rc

>Bengt Kleberg -- RC => POSIX
>Tom Culliton -- Re: RC => POSIX
>Bengt Kleberg -- Re: RC => POSIX
>Tom Culliton -- Re: RC => POSIX
>Malte Uhl -- Re: RC => POSIX 
>Tom Culliton -- Re: RC => POSIX
>Alan Watson -- Re: RC => POSIX
>Tom Culliton -- Re: RC => POSIX
>Scott Schwartz -- Re: RC => POSIX 
>Greg A. Woods -- Re: RC => POSIX

A quick and necessarily incomplete reply to all this mail.

First of all I want to resist posixifying rc. It is a shell which in fact
enjoys wide portability, and I think it would be a mistake to limit the
use of subsequent versions to posix systems.

I agree that the ANSI header files are probably a mistake. The reason why
they are a mistake is again that they limit portability.

Byron.



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
  1997-03-06 10:16 Bengt Kleberg
@ 1997-03-07  1:45 ` Greg A. Woods
  0 siblings, 0 replies; 20+ messages in thread
From: Greg A. Woods @ 1997-03-07  1:45 UTC (permalink / raw)
  To: Bengt Kleberg; +Cc: rc

[ On Thu, March 6, 1997 at 05:16:15 (-0500), Bengt Kleberg wrote: ]
> Subject: RC => POSIX
>
> What if we wrote rc to posix (or UNIX(tm) if posix isn't enough) and
> removed as much of the #ifdef's as possible. Then, on systems without
> posix support, we could  create a posix library for that operating
> system. Only covering the missing posix calls that rc uses, ofcourse.

It would be far more productive and result in a far more portable
product to integrate GNU Autoconf et al and didn't I just see a note
about es being autoconf'ed pass by here earlier?  Taking the autoconf
support from es should be trivial, esp. to any rc-internals programmer
with any experience using autoconf.

The GNU Autoconf philosophy is similar in some ways to what you suggest,
esp. in that autoconf'ed packages usually provide a compatability
library for those system functions the software uses but which are not
always available on all systems.  However the autoconf style isn't
anywhere nearly so restrictive as porting directly to plain POSIX would
be.

(BTW, w.r.t. the GNU readline signal problems, my adivce is don't use
GNU readline -- it isn't very good at what it does, is far too big, and
is very difficult to integrate into a program that tries to do job
control.  There were other command-line editing libraries for rc long
ago, and there are other new ones too that might be tried.  I've had
good luck with the command-line editing support in pdksh and it seems to
integrate well with a shell, and it supports both vi and emacs modes.)

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-06 17:40 Tom Culliton
  0 siblings, 0 replies; 20+ messages in thread
From: Tom Culliton @ 1997-03-06 17:40 UTC (permalink / raw)
  To: alan, rc

> The behaviour of rc is, for all intents and purposes, fixed. We are

Agreed...  More or less...  We never did get an official version with
read in it as Byron discussed once.

> talking about rc-1.5 not because we want new features or want bugs
> fixed,

Even if we don't add new features I'd sure like to see bugs fixed!  And
yes, there are bugs, software without bugs is even rarer than being 
alive and not having dirty laundry.  I'd like to see a 1.5 with the   
known good fixes incorporated before we start talking about any major
rewrites.  Personally I plan to do my part by running rc through every
static and dynamic checker available to me, and posting fixes for 
anything that turns up.

> but because we want rc-1.4 to work on new iron. Presumably,
> those people with old iron can continue to run rc-1.4.

This was exactly what I was arguing against!

Tom


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
       [not found] <199703061512.KAA21040@explorer2.clark.net>
@ 1997-03-06 16:57 ` Malte Uhl
  0 siblings, 0 replies; 20+ messages in thread
From: Malte Uhl @ 1997-03-06 16:57 UTC (permalink / raw)
  To: rc


> 	> The problem is harder than that in rc's case.  Signal semantics make a
> 	> good example.  To be really posixy you'd use sigaction(), and while
> 	> you can write signal() in terms of sigaction, the reverse is not very
> 	> doable.  The differences between BSD and SysV signal semantics are one
> 	> of the reasons that RC has a bunch of #if's.
> 
> 	And that's exactly his point! Why use BSD or SysV semantics when you can do 
> 	it posixly correct?
> 
> 	> Others include optional
> 	> features such as readline, nonstandard OS features that make something
> 	> work in a better, safer way when they're present such as /dev/fd and
> 	> kernel recognition of "#!" in executable scrpts.  All your proposal
> 	> would do is move the #if's into the compatibility library.
> 
> 	Again, that's the very point: To seperate the shells code from the OS stuff 
> 	as much as possible.
> 
> 	I'd even go further suggesting to drop all the "ANSI compatibility" headers 
> 	Byron once wrote. They are a major source of problems porting rc to different 
> 	platforms and to maintain it. Frequently, the declarations made in them are 
> 	slightly incompatible with the systems declarations, although hard clashes 
> 	are rare.
> 
> 	Summarising the intense discussions a few years back, we've concluded not to 
> 	add new features so, rewriting to Posix and Xopen specs gets my vote!
> 
> 	If rc was to be changed, I'd suggest setting the status variable to the 
> 	result of a backquote command in an assignment, as in
> 
> 		; x=`false || echo error
> 		error
> 		;
> 
> 	Malte
> 
> 




^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-06 16:54 Tom Culliton
  0 siblings, 0 replies; 20+ messages in thread
From: Tom Culliton @ 1997-03-06 16:54 UTC (permalink / raw)
  To: Uhl, rc

> From: Malte Uhl <Uhl@rrz.Uni-Koeln.DE>
>
>Agreed, "all the old BSD and SysV systems" would fall behind. But, frankly, I 
>can hardly remember the last computer without Posix and Xopen support. Can 
>you provide any numbers to support your point? I'd be very interested in them!
>
> Malte

How does three of the six systems that I've ported rc to strike you?
There's a lot of old iron out there doing useful work.  Ask Byron, I'm
sure he had a lot of mail from folks with strange incompatibilities.

Tom


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-06 15:22 Tom Culliton
  0 siblings, 0 replies; 20+ messages in thread
From: Tom Culliton @ 1997-03-06 15:22 UTC (permalink / raw)
  To: Uhl; +Cc: rc

> From: Malte Uhl <Uhl@rrz.Uni-Koeln.DE>
>
> And that's exactly his point! Why use BSD or SysV semantics when you can do 
> it posixly correct?

Uhm... So it'll work on those systems which don't have Posix support?
After all, the whole point of #if's for portability is... PORTABILITY!

To do wonderful new Posix rewrite of rc for "Posix" systems so it
suddenly doesn't work on all the old BSD and SysV systems that it has
worked on "all along" would be pretty darned silly in my opinion.
I've had to work on and port code to, too many "backwards" systems to
leave somebody else swinging in the wind like that.

Tom


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-06 14:09 Bengt Kleberg
  0 siblings, 0 replies; 20+ messages in thread
From: Bengt Kleberg @ 1997-03-06 14:09 UTC (permalink / raw)
  To: rc, culliton


> From rc-owner@hawkwind.utcs.toronto.edu Thu Mar  6 14:48:52 1997
> From: Tom Culliton <culliton@clark.net>
> Date: 	Thu, 6 Mar 1997 08:46:06 -0500
> To: Bengt.Kleberg@ms.uab.ericsson.se, rc@hawkwind.utcs.toronto.edu
> Subject: Re: RC => POSIX
> 
> > What if we wrote rc to posix (or UNIX(tm) if posix isn't enough) and
> > removed as much of the #ifdef's as possible. Then, on systems without
> > posix support, we could  create a posix library for that operating
> > system. Only covering the missing posix calls that rc uses, ofcourse.
> >
...deleted explanation why this wouldn't be a good idea
> >

OK, I just like the idea, have tried it successfully (with far fewer
target systems) and hoped it would be doable.

> All your proposal
> would do is move the #if's into the compatibility library.

Actually I meant to use a specific library for each operating system,
so there would be several libraries with no #ifdef's in any of them.
This is probably just a case of personal taste. I prefer several
libraries, others prefer serveral #ifdef's.

Best Wishes, Bengt
--------------------------------------------------------------------
Email: Bengt.Kleberg@enea.se (Enea Data AB, Sweden)
Disclaimer: Nothing abovementioned has any connection to Enea Data AB
``At the moment money does indeed make the world go round but unfortunately
  the direction of that applied rotation is all downhill.'' fleecy@netreach.net


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: RC => POSIX
@ 1997-03-06 13:46 Tom Culliton
  0 siblings, 0 replies; 20+ messages in thread
From: Tom Culliton @ 1997-03-06 13:46 UTC (permalink / raw)
  To: Bengt.Kleberg, rc

> What if we wrote rc to posix (or UNIX(tm) if posix isn't enough) and
> removed as much of the #ifdef's as possible. Then, on systems without
> posix support, we could  create a posix library for that operating
> system. Only covering the missing posix calls that rc uses, ofcourse.
>
> Has this kind of thing been done before and failed?
> Comments/Suggestions/xxx.

The problem is harder than that in rc's case.  Signal semantics make a
good example.  To be really posixy you'd use sigaction(), and while
you can write signal() in terms of sigaction, the reverse is not very
doable.  The differences between BSD and SysV signal semantics are one
of the reasons that RC has a bunch of #if's.  Others include optional
features such as readline, nonstandard OS features that make something
work in a better, safer way when they're present such as /dev/fd and
kernel recognition of "#!" in executable scrpts.  All your proposal
would do is move the #if's into the compatibility library.

BTW - While I'm thinking of it has anyone looked at how much effort it
would take to make the /dev/fd code work with a /proc file system?  I
mean without putting symbolic links in /dev.  Actually if that works,
as someone suggested, it seems like the code change should be easy...

Tom


^ permalink raw reply	[flat|nested] 20+ messages in thread

* RC => POSIX
@ 1997-03-06 10:16 Bengt Kleberg
  1997-03-07  1:45 ` Greg A. Woods
  0 siblings, 1 reply; 20+ messages in thread
From: Bengt Kleberg @ 1997-03-06 10:16 UTC (permalink / raw)
  To: rc


Greetings,

I know that this probably will generate a lot of work, but I'm willing
to do as much of it as I can (he says, safe in the knowledge that he
only has Solaris2). Perhaps as the only change for rc-1.6?

What if we wrote rc to posix (or UNIX(tm) if posix isn't enough) and
removed as much of the #ifdef's as possible. Then, on systems without
posix support, we could  create a posix library for that operating
system. Only covering the missing posix calls that rc uses, ofcourse.

Has this kind of thing been done before and failed?
Comments/Suggestions/xxx.

(I have done this for some code that run's under 3 similar real time
OS's and like the result. But then I don't like #ifdef).

Best Wishes, Bengt
--------------------------------------------------------------------
Email: Bengt.Kleberg@enea.se (Enea Data AB, Sweden)
Disclaimer: Nothing abovementioned has any connection to Enea Data AB
``At the moment money does indeed make the world go round but unfortunately
  the direction of that applied rotation is all downhill.'' fleecy@netreach.net


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~1997-03-30  5:05 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-03-06 17:15 RC => POSIX Alan Watson
1997-03-06 17:54 ` Scott Schwartz
  -- strict thread matches above, loose matches on Subject: below --
1997-03-29 20:23 Bengt Kleberg
1997-03-27  9:58 Malte Uhl
1997-03-26 11:54 Byron Rakitzis
1997-03-26 16:45 ` Greg A. Woods
1997-03-26  8:33 Bengt Kleberg
1997-03-26 16:38 ` Greg A. Woods
1997-03-25 22:30 Byron Rakitzis
1997-03-24  9:18 Bengt Kleberg
1997-03-24 20:22 ` Greg A. Woods
1997-03-08  0:13 Byron Rakitzis
1997-03-06 17:40 Tom Culliton
     [not found] <199703061512.KAA21040@explorer2.clark.net>
1997-03-06 16:57 ` Malte Uhl
1997-03-06 16:54 Tom Culliton
1997-03-06 15:22 Tom Culliton
1997-03-06 14:09 Bengt Kleberg
1997-03-06 13:46 Tom Culliton
1997-03-06 10:16 Bengt Kleberg
1997-03-07  1:45 ` Greg A. Woods

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).