procfs.c thinks pid's can't be bigger than 99999

procfs.c thinks pid's can't be bigger than 99999

[John Hughes]

but on some systems, for example UnixWare NSC they
can be quite a lot bigger.

--- procfs.c.orig       Tue May 15 02:03:36 2001
+++ procfs.c    Mon Jul  2 14:40:05 2001
@@ -295,7 +295,7 @@
 #  define AS_PROC_NAME_FMT     "/proc/%d/as"
 #  define MAP_PROC_NAME_FMT    "/proc/%d/map"
 #  define STATUS_PROC_NAME_FMT "/proc/%d/status"
-#  define MAX_PROC_NAME_SIZE sizeof("/proc/99999/lwp/8096/lstatus")
+#  define MAX_PROC_NAME_SIZE sizeof("/proc/1048576/lwp/8096/lstatus")
 # endif
 /* the name of the proc status struct depends on the implementation */
 typedef pstatus_t   gdb_prstatus_t;

-- 
John Hughes <john@Calva.COM>
 

Re: procfs.c thinks pid's can't be bigger than 99999

[Michael Snyder]

John Hughes wrote:
> 
> but on some systems, for example UnixWare NSC they
> can be quite a lot bigger.
> 
> --- procfs.c.orig       Tue May 15 02:03:36 2001
> +++ procfs.c    Mon Jul  2 14:40:05 2001
> @@ -295,7 +295,7 @@
>  #  define AS_PROC_NAME_FMT     "/proc/%d/as"
>  #  define MAP_PROC_NAME_FMT    "/proc/%d/map"
>  #  define STATUS_PROC_NAME_FMT "/proc/%d/status"
> -#  define MAX_PROC_NAME_SIZE sizeof("/proc/99999/lwp/8096/lstatus")
> +#  define MAX_PROC_NAME_SIZE sizeof("/proc/1048576/lwp/8096/lstatus")
>  # endif
>  /* the name of the proc status struct depends on the implementation */
>  typedef pstatus_t   gdb_prstatus_t;

Well, actually, aren't we going to run into trouble if 
pids are bigger than 16 bits?  Or did Kevin Buettner's 
recent changes take care of that?

Other than that, I have no problem with this change.

Re: procfs.c thinks pid's can't be bigger than 99999

[Kevin Buettner]

On Jul 2, 11:56am, Michael Snyder wrote:

> John Hughes wrote:
> > 
> > but on some systems, for example UnixWare NSC they
> > can be quite a lot bigger.
> > 
> > --- procfs.c.orig       Tue May 15 02:03:36 2001
> > +++ procfs.c    Mon Jul  2 14:40:05 2001
> > @@ -295,7 +295,7 @@
> >  #  define AS_PROC_NAME_FMT     "/proc/%d/as"
> >  #  define MAP_PROC_NAME_FMT    "/proc/%d/map"
> >  #  define STATUS_PROC_NAME_FMT "/proc/%d/status"
> > -#  define MAX_PROC_NAME_SIZE sizeof("/proc/99999/lwp/8096/lstatus")
> > +#  define MAX_PROC_NAME_SIZE sizeof("/proc/1048576/lwp/8096/lstatus")
> >  # endif
> >  /* the name of the proc status struct depends on the implementation */
> >  typedef pstatus_t   gdb_prstatus_t;
> 
> Well, actually, aren't we going to run into trouble if 
> pids are bigger than 16 bits?  Or did Kevin Buettner's 
> recent changes take care of that?

My recent changes took care of that.

> Other than that, I have no problem with this change.

I think John's change is a step in the right direction, but the name
is still not large enough.  In AIX 5, the pids and tids seem to be
able to occupy all of 32 bits.  Therefore, I propose that we use
the following:

  #define MAX_PROC_NAME_SIZE sizeof("/proc/1234567890/lwp/1234567890/lstatus")

Note that 2^32-1 is 4294967295 which requires ten digits.  Using
"1234567890" makes it obvious that ten digits are needed.

Kevin

Re: procfs.c thinks pid's can't be bigger than 99999

[Michael Snyder]

Kevin Buettner wrote:
> 
> On Jul 2, 11:56am, Michael Snyder wrote:
> 
> > John Hughes wrote:
> > >
> > > but on some systems, for example UnixWare NSC they
> > > can be quite a lot bigger.
> > >
> > > --- procfs.c.orig       Tue May 15 02:03:36 2001
> > > +++ procfs.c    Mon Jul  2 14:40:05 2001
> > > @@ -295,7 +295,7 @@
> > >  #  define AS_PROC_NAME_FMT     "/proc/%d/as"
> > >  #  define MAP_PROC_NAME_FMT    "/proc/%d/map"
> > >  #  define STATUS_PROC_NAME_FMT "/proc/%d/status"
> > > -#  define MAX_PROC_NAME_SIZE sizeof("/proc/99999/lwp/8096/lstatus")
> > > +#  define MAX_PROC_NAME_SIZE sizeof("/proc/1048576/lwp/8096/lstatus")
> > >  # endif
> > >  /* the name of the proc status struct depends on the implementation */
> > >  typedef pstatus_t   gdb_prstatus_t;
> >
> > Well, actually, aren't we going to run into trouble if
> > pids are bigger than 16 bits?  Or did Kevin Buettner's
> > recent changes take care of that?
> 
> My recent changes took care of that.
> 
> > Other than that, I have no problem with this change.
> 
> I think John's change is a step in the right direction, but the name
> is still not large enough.  In AIX 5, the pids and tids seem to be
> able to occupy all of 32 bits.  Therefore, I propose that we use
> the following:
> 
>   #define MAX_PROC_NAME_SIZE sizeof("/proc/1234567890/lwp/1234567890/lstatus")
> 
> Note that 2^32-1 is 4294967295 which requires ten digits.  Using
> "1234567890" makes it obvious that ten digits are needed.

Good, this has my approval.
Michael

Re: procfs.c thinks pid's can't be bigger than 99999

[Andrew Cagney]

> but on some systems, for example UnixWare NSC they
> can be quite a lot bigger.
> 
> --- procfs.c.orig       Tue May 15 02:03:36 2001
> +++ procfs.c    Mon Jul  2 14:40:05 2001
> @@ -295,7 +295,7 @@
>  #  define AS_PROC_NAME_FMT     "/proc/%d/as"
>  #  define MAP_PROC_NAME_FMT    "/proc/%d/map"
>  #  define STATUS_PROC_NAME_FMT "/proc/%d/status"
> -#  define MAX_PROC_NAME_SIZE sizeof("/proc/99999/lwp/8096/lstatus")
> +#  define MAX_PROC_NAME_SIZE sizeof("/proc/1048576/lwp/8096/lstatus")
>  # endif
>  /* the name of the proc status struct depends on the implementation */
>  typedef pstatus_t   gdb_prstatus_t;


Um, I think it would be a lot better to size the buffer dynamically. 
xasprintf() is one way of doing that.  Anyway, I think the main thing is 
to fix the buffer overrun not hide it :-)

	Andrew