Re: LYNX-DEV Re: DOS, DOS and Windows

[Klaus Weide]

On Sat, 26 Oct 1996, Foteos Macrides wrote:

> "Hiram Lester, Jr." <address@hidden> wrote:
> >On Fri, 25 Oct 1996, Foteos Macrides wrote:
> >
> >> >Does that mean changing:
> >> >
> >> >PUBLIC int foo ARGS2 (int,foo1,int,foo2)
> >> >
> >> >with 
> >> >
> >> >extern int foo(int foo1, int foo2)
> >> 
> >>    That's the basic idea, though that conversion is incorrect.
> >> The point is that the W3C Reference Library has changed from K&R
> >> to ANSI C, and has changed from it's former platform/flavor #ifdef'ing
> >> to autoconf'ing, so it seems like this is a good time to do the
> >> equivalent conversion for Lynx as a whole, as well.
> >
> >So, for that example, what would be the CORRECT conversion?
> 
>       The K&R macros are in ./WWW/Library/Implementation/HTUtils.h
> You need to do what amounts to the translations for __STDC__
> 
> [...]
> #define PUBLIC                  /* Accessible outside this module     */
> #define PRIVATE static          /* Accessible only within this module */
> 
> #ifdef __STDC__
> #define CONST const             /* "const" only exists in STDC */
> #define NOPARAMS (void)
> #define PARAMS(parameter_list) parameter_list
> #define NOARGS (void)
> #define ARGS1(t,a) \
>                 (t a)
> [...]

If the goal is (for now) just to _test_ what platforms have problems
with ANSI C syntax, one could just let the preprocessor do the job
rather than converting all source files manually.  Just replace the
"#ifdef __STDC__" above with "#if 1". 

>       "PUBLIC " should be replaced by "" in all .c modules, and with
> "extern " in all .h modules (some of the .c modules may have prototyping
> of functions within them, instead of in headers, and for those you
> specify extern or not depending on whether the actual function is in
> that .c module).
> 
>       "PRIVATE" should be replaced by "static" in both .c and .h
> modules.

The definitions and use of PUBLIC and PRIVATE are not about to the
question of K&R vs. ANSI C.  They are independent of whether __STDC__
is defined or not, and the new Ref Lib is still using them.  See:

   Linkname: C Programming Style in libwww
        URL: http://www.w3.org/pub/WWW/Library/User/Style/
 
>       "CONST" should be lowercased in both .c and .h modules.
>       
>       "PARAMS ((...))" should be stripped to just the "(...)" throughout.
>       
>       "ARGS# (...)" should have the "ARGS#" stripped, and in the "(...)",
> the commas between the types and argument names should be removed.
> 
>       "NOPARAMS" and "NOARGS" should be replaced with "(void)".
> 
>       You also should check all modules for #ifdef'ing based
> on __STD__ and modify them accordingly.  In addition, you want
> a breakout of the most current W3C Reference Library available,
> to see how it deals with any problems those conversions create,
> and to do any new #ifdef'ing homologously.
> 
>       Once the Lynx v2.6+Composite code with those mods is
> verified to compile and link on a reasonable range of flavors,
> an autoconf for the libwww-FM should be created in a manner
> homologous to that for the current Reference Library, and then
> a compatible one for the LYFoo modules.
> 
>       At that point, we can again use the Reference Library
> as a Reference, and work toward an uprade to it, with for-Lynx
> expansions, but should be able to keep whatever is done along
> that road broadly distributeable for generally use (i.e. not
> just for developers).
> 
>       The hard part will be getting the current #ifdef'ing,
> based on the platform/flavor model of the old libwwws, replaced
> with #ifdef'ing based on things like POSIX compliance.  I think,
> though, that if we do these things with the v2.6+Composite code.

Comments on my attempt to move in the direction of the new library are
still welcome. <URL: http://lynx.cc.ukans.edu/lynx-dev/9609/index.html>.

I don't know/understand what it has to do with POSIX, though.

> seeking to make that code still do what it was doing before the
> conversion, it's more likely to really work out (at least, that's
> the way I would go about it if I weren't on vacation 8-).

As I have tried to say before, massively modifying the current Lynx code
by eliminating the macros from HTUtils.h is not necessary in order to
"use the Reference Library as a Reference, and work toward an upgrade 
to it".  

   Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;