> On Mon, 16 Oct 1995, Carlo E. Prelz wrote:
>
> > Hi. Just as I was writing a whining message about 1.3.34 still not
> > working OK with SCSI, I saw the next release, and I saw the light :-)
> > Scsi now works OK with my discs, CDrom and tape. Thanks!
> >
> > I had noted a problem with the new release of the PPP software: after
> > setting up the link, pppd would die with signal 11... I used my faithful
> > debugger (shame, shame) and found out that the string buffer that is
> > used for reading /proc/net/route was undersized (at 100, while 128
> > characters are generated). This is the patch that I used (refers to
> > ..../ppp-2.2.0a/pppd/):
> >
> > --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
> >
> > --- sys-linux.c~ Mon Oct 16 16:10:10 1995
> > +++ sys-linux.c Mon Oct 16 17:33:54 1995
> > @@ -945,7 +945,7 @@
> > */
> >
> > FILE *route_fd = (FILE *) 0;
> > -static char route_buffer [100];
> > +static char route_buffer [256];
> >
> > static char *path_to_route (void);
> > static int open_route_table (void);
> >
> > --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
> >
> > (I am used to size unknown buffers to 256... the original authors are
> > welcome to put the number they prefer)
>
> Why is this code using a magic number anyway, instead of a symbol? If this
> isn't symbolized anywhere, it should be. Not having a shared value is
> causing problems.
Mah, good question. I have no idea. I also have no idea whether the
output of /proc/route will be stable, and if the size of the buffer is
in any way available (maybe in a kernel include...). I made as small a
patch as possible. Then it is up, to the PPP software maintainers to make
things nicer.
Ciao
Carlo