Mail Archives: djgpp-workers/1998/03/24/10:33:02
Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be> wrote:
> Salvador Eduardo Tropea (SET) wrote:
> >
> > Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be> wrote:
> >
> > > I think your patch should not specify DENYNONE, but DENYWRITE. It better
> > > simulates the compatibility mode behaviour. But, your patch won't help a
> > > bit in this case when the file was already open in compatibility mode.
> > > That is the mean reason why I think that all open functions never should
> > > use the compatibility mode.
> >
> > That was the idea, but as it can produce problems the final patch doesn't use a
> > predefined value and the user must select what s/he want to use.
>
> Have I had a chance to see that final patch, I don't recall I have? I
> cannot find it anywhere.
Was posted here (djgpp-workers). I don't have it right now but basically it
defines a new variable (__djgpp_share_flags) where you can put the default
share flags. Then if you call open without specifying any share flag (the fopen
case) open uses the __djgpp_share_flags. So the patch doesn't affect any
working program, but allows to my editor define:
int __djgpp_share_flags=... to deny any thing.
> > > The fact is that opening in COMPAT mode such a program IS broken under
> > > several OS versions.
> > > I see no way to solve both of these problems, but it seems that an
> > > unconditional share flag solves it better.
> >
> > Remmember that other compilers use COMPAT mode.
>
> So programs compiled with other compilers are buggy under (hmmm)
> multitasking OS'es, what's your point?
From my point of view: Yes that's a buggy thing. From the reality: In UNIX the
default behavior is more like COMPAT mode without share (you have functions to
lock, set access rights, etc, but you must fine tune it) so I don't know if one
(or more) GNU programs could break with share flags.
> > In my opinion the actual patch
> > (where you select the flag) is the one that will generate less problems.
>
> Well I haven't seen it, but from your description here:
> It seems indeed a good idea to use the sharing mode COMPAT by default,
> and and flag controlling whether a more enhanced sharing interface
> should be used. This way old programs won't be broken and newer and
> older corrected programs can benefit from this new behaviour.
> It is some pitty that ANSI has no way of controlling this sharing
> behaviour. It seems that those ANSI committee people have been
> brain-washed by AT&T (That's not only a funny remark, I also mean it)
Well perhaps POSIX stablish some protection scheme (don't know if the glibc
features are POSIX), but normally ANSI is VERY generic and that looks like an
specific topic.
> > Perhaps the modifications that you say can be introduced but conditionally, I
> > mean having a flag to enable it.
> > The main problem is to know if one or more applications will be affected by it.
>
> Can't a crt1 startup flag be used to control this behaviour?
Currently my patch uses a variable defined to 0 in one .o file (inside libc) so
it doesn't affect to old programs, you just need to redefine the variable in
your code overwriting the one in libc.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
CQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -