Re: changes to command line parsing

Ed,

> In cleaning up the preproc.c interfaces, I notice that several functions 
> are exported solely for the use of nasm.c when it processes command line 

Yes. To handle -I and -P, as well as -D and -U.

> options.  It occurred to me that it might provide a better and more 
> concise interface if the interface were made a little more generic, 

In my cleaned up version (NASM64), it looks like this:

nasm.h
------
typedef struct {
  void ( *reset ) ( Uint32_t s_hash_buckets, Uint32_t m_hash_buckets, const 
Char_t *file );
  Char_t *( *getline ) ( Bool_t line_continuation );
  void ( *cleanup ) ( void );
  void ( *stdmac_ofmt) ( const Char_t **stdmac );
  void ( *include_path ) ( const Char_t *path );
  void ( *pre_include ) ( const Char_t *fname );
  void ( *pre_define ) ( const Char_t *definition );
  void ( *pre_idefine ) ( const Char_t *definition );
  void ( *pre_undef ) ( const Char_t *definition );
  void ( *pre_undefi ) ( const Char_t *definition );
} pp_t;

pp_nasm.c
---------
pp_t pp_nasm = {
  pp_nasm_reset,
  pp_nasm_getline,
  pp_nasm_cleanup,
  pp_nasm_stdmac_ofmt,
  pp_nasm_include_path,
  pp_nasm_pre_include,
  pp_nasm_pre_define,
  pp_nasm_pre_idefine,
  pp_nasm_pre_undef,
  pp_nasm_pre_undefi
};

pp_null.c
---------
pp_t pp_null = {
  pp_null_reset,
  pp_null_getline,
  pp_null_cleanup,
  pp_null_stdmac_ofmt,  /* just returns */
  pp_null_include_path, /* just returns */
  pp_null_pre_include,  /* just returns */
  pp_null_pre_define,   /* just returns */
  pp_null_pre_idefine,  /* just returns */
  pp_null_pre_undef,    /* just returns */
  pp_null_pre_undefi    /* just returns */
};

Aside from that, pp_nasm.c has access to:

extern err_t err;    /* global error handling routine */
extern eval_t eval;  /* global evaluator routine */
extern lst_t *lst;   /* global list file generator */
extern ofmt_t *ofmt; /* global output format */
extern pass_t pass;  /* global current pass */

while pp_null.c has access to:

extern err_t err;    /* global error handling routine */
extern lst_t *lst;   /* global list file generator */

That is, I stopped handing these around as function parameters.

> since my primary interest in cleaing up the interface is to allow for 
> alternate preprocessors to be built.

Can you elaborate?
What sort of preprocessing?
And what kind of command line arguments do you have in mind for that?

Btw, in my pp_nasm.c, I support %OPTION to control preprocessor behavior.
So far:

%OPTION [-|+]LOOKUP
%OPTION [-|+]EXPAND

Their documentation reads:

  If used with the -LOOKUP or +LOOKUP argument, the %OPTION preprocessor
  directive selects whether a context-local preprocessor variable and/or
  single-line macro (but not label) is, during expansion (but not during
  definition), looked up in an(y) outer context(s), whenever the current
  context does not provide a suitable definition to expand from.

and:

  If used with the -EXPAND or +EXPAND argument, then the %OPTION prepro-
  cessor directive selects whether macro-local preprocessor variables or
  single-line macros and labels are converted ("%%id" into "..@<n>.id"),
  and multi-line macro arguments are expanded, after they've been or be-
  fore they'll be emitted into a list file.

That is, I didn't go for command line options -- precisely because they
would have been specific to this preprocessor. Yes, -I and -P, as well
-D and -U fall into the same category; however, I didn't want to change
these existing command line options... just avoid introducing new ones.
So I went for a %OPTION directive instead.  :)

Last but not least, you might want to try and keep the preprocessor as
modular as possible. Think NASM without the assembler portion. Or using
the NASM preprocessor on NASM-like but non-NASM input. (After cleaning
it up a lot, and adding plenty of new functionality, I realized that it
can be used for more than just NASMish assembly code.)


                
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/