Subject: Re: core dump filename format
To: None <tech-userlevel@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-userlevel
Date: 09/08/1999 10:54:20
> I though p_comm was the same thing as argv[0].

It usually is.  But there's no reason argv[0] passed to exec has to
bear any relation to the pathname passed to exec (though it
conventionally does, that's just a convention), and the latter seems to
be what p_comm is derived from.

>> Another potentially useful format would be one that would get the
>> signal that caused the core.  This could be either name or number,
>> preferably with both forms available
> Good idea.  What letters ? :)

My first impulse is to suggest %s and %S, but I think avoiding %s
entirely would be a good idea.  (I'd also be inclined to avoid %d.)

Perhaps %S0 and %Sa (numeric and alpha forms)?  %k and %K ("k"illing
signal)?

>>> [getrlimit/setrlimit] would now take a void * parameter, which
>>> would be a struct rlimit * or char *,
>> I'm not sure I like this; it breaks binary compatability on machines
>> where struct pointers and void pointers don't "smell the same" (eg,
>> are different sizes).  Does NetBSD currently run on any such
>> machines?

(I suspect the answer to the last question is "no", in which case this
is rather a non-issue.  I'm not even sure gcc supports such
architectures.)

>> [...maybe sysctl(3) / __sysctl(2)...] would also sidestep the
>> question of how to return a string of more or less unlimited length
> This should be limited to MAXPATHLEN, isn't it ?

Since fairly few formats will be longer than the text they can
generate, it's unlikely.  We certainly could decree by fiat that the
coredump format is limited to MAXPATHLEN.... :-)

>> through the getrlimit() interface, even as extended.
> Won't /copyoutstr DTRT ?

Well, as far as copying it goes, presumably.  I'm just uneasy around
interfaces that return strings of potentially large size without taking
a size parameter.  termcap used this for tgetent() and look at the mess
that resulted when termcap entries got large.  getwd() did this and it
proved to be enough of a problem that getcwd() was created.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B