> 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.
Mark H. Wood, Lead System Programmer MWOOD@INDYVAX.IUPUI.EDU
Those who will not learn from history are doomed to reimplement it.