Re: [MiNT] expanded /proc vs new /kern

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

Jo-Even.Skarstein@gjensidige.no wrote:
> > I previously quoted that part and it says "_might_ have an entry
> > miniwin.003" which still doesn't explicit that it must be 8+3; it
> > only states filename without extension, plus an extension
> > consisting of the pid.
> 
> That's right, nowhere does it explicitly say that the base of the filename
> is limited to 8 characters. The only thing that's explicitly documented is
> the length and format of the extension. This basically means that you could
> change /proc to support processnames like "This-is-a_REALLY_weird
> filename.with odd_ÆØÅ[]characters.in.it.348" and it wouldn't contradict the
> docs. Naturally, I'm going to update my software to support this highly
> critical and important feature ;-)

Long filenames are one thing, case-sensitiveness another.  I'm at work,
cannot verify it, but I think that /proc is case-preserving, not
case-sensitive, correct?  I guess that the compendium doesn't say
anything about case, does it?  However, making /proc case-sensitive
would probably be dangerous.

We are not the supreme court here.  Saying to some programmer, "your
program is dirty because it relies on 8+3 in /proc" is not adequate.  It
is pretty obvious that /proc is and has always been 8+3.  Whether the
compendium (or even the MiNT docs) comment on that question or not is
not that relevant in my eyes.  ERS was usually very careful with such
statements, you will find a lot of "don't rely on that, it may change in
the future" but not here.

Yes, I know what you want to reply, SIGPWR ...

That's a different case.  If the last signal was #30 it is not hard to
guess that this leaves the opportunity to define a new signal #31
later.  But allowing longer filenames in /proc is a surprising change in
the system behavior.  Furthermore it is potentially dangerous because
one typical error caused by this change would be a buffer overflow that
- without memory protection - can lead to a completely unstable system. 
Right, the same argument kind of applies to SIGPWR (printf ("got signal
%s\n", signames[sig]) but giving up 8+3 looks more dangerous to me.

Besides, it's not necessary.  A well-written program (that actually
cares about the name of the executable) will probably ignore the
filename altogether and has better means of retrieving this information.

Ciao

Guido