Re: [PATCH] procfs: match /proc/self/maps address width to Linux

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-2105081889-1785751339=:2896
Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.NEB.4.64.2608031103071.2896@ugly>

On Sat, 1 Aug 2026, Robert Swindells wrote:
> Edgar Fu=C3=9F <[email protected]> wrote:
>> Didn't we have -o linux for things like that?
>
> We do, the implementation of the emulated linux procfs is mingled in
> with the NetBSD native stuff.

Indeed. -o linux is the default now, so the question is=20
what happens with -o nolinux (-o linux is no longer documented)

/proc/self/maps is documented as being for Linux compatibility,=20
but is explicitly excluded from the 'what happens if you specific -o=20
linux' list of files (which is itself wrong given the same man page only=20
documented -o nolinux).

> The 'width' variable being modified by the patch is only used when
> '-o linux' has been specified when mounting the filesystem.

If you don't give any options, you get what was historically enabled with=
=20
-o linux.

> One review question could be whether it would be better to modify the
> call to snprintf(3) to not use 'width' at all.

I think that /proc/self/maps should be implementation-compatible with=20
Linux. Not using width at all would not be compatible as Linux zero-pads=20
to 8 (but no more).

Henrique's question really is, does anything actually care about the=20
layout of maps outside of Linux apps (and Linuxy apps being built for=20
NetBSD)? If there are no counter-arguments, I'll commit his patch.

--=20
Stephen

--0-2105081889-1785751339=:2896--