[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Re: LYNX-DEV lynx_w32.zip feedback
From: |
T.E.Dickey |
Subject: |
Re: lynx-dev Re: LYNX-DEV lynx_w32.zip feedback |
Date: |
Wed, 15 Apr 1998 12:28:42 -0400 (EDT) |
> > > > (yes, I'm aware that it would run about 1% slower if we pass all of
> > > > that
> > > > stuff on the stack - but it would be much simpler to maintain).
> > >
> Yay! This needs to be done. I gagged when I saw in LYMain.C:
> *stderr = *LYTraceLogFP;
>
> -- I wondered, "Are you supposed to be able to do that?" The answer
> is, "No. See ANSI C, Sect. 4.9.3 Files":
>
> [ ... ]
> The address of the FILE object used to control a stream may be
> significant; a copy of the FILE object may not necessarily serve in
> place of the original.
it is rather ugly (but only ten years ago when C was standardized, most
stdio implementations afaik still used an array for the FILE pointers - so
I'd assume this looked like a viable solution because it hadn't been well
tested on more than 2-3 platforms.
> > We could work around that by making the macro have the if statement
> > the way it does now:
> > #define DPRINTF(p) if (TRACE) dprintf p
> >
> Or, should it be:
>
> > #define DPRINTF(p) { if (TRACE) dprintf p; }
>
> to avoid dangling-else problems? The syntax of C leaves no proper way
> to do this.
well, if I put the if inside the function we don't have to worry about
the compilers that don't like the curly braces either.
> <make_finger_down_throat_gesture>
> > to make it reliable as well, we'd probably do what I've seen in other
> > places
> > (close & reopen the file after each message).
> >
> </make_finger_down_throat_gesture>
> -- but that could also be made optional with a macro.
it certainly could (I wouldn't want to do it on a system that works properly).
--
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey