Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1867
| From | Kaz Kylheku <686-678-9105@kylheku.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Parsing partial sentences |
| Date | 2017-04-30 16:31 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <17-04-028@comp.compilers> (permalink) |
| References | <17-04-001@comp.compilers> <17-04-023@comp.compilers> <17-04-024@comp.compilers> <17-04-027@comp.compilers> |
On 2017-04-29, Marco van de Voort <marcov@toad.stack.nl> wrote:
> On 2017-04-27, Kaz Kylheku <686-678-9105@kylheku.com> wrote:
>>> In a word NO. #defines are always strings even when they look like
>>> constants, something I have found out the hard way. There have only been
>>> two ways that I have successfully dealt with #defines: a preprocessor
>>> pass or later and much faster pipeline the processing of C source and
>>> add the defined definition processing into part of the source fetch
>>> handling.
>>
>> If we allow Pascal to be extended with a macro preprocessor,
>
> I think most interest in C->Pascal header translators is for (semi)automated
> translation of 3rd party library headers, not converting complete programs.
OP wrote that he's writing a C to Pascal translator. The face value
interpretation of that is that it handles programs.
Handling only headers would be the likely focus of a project for
automatically generating Pascal foreign function interface bindings
for C libraries: C to Pascal interface translation (C � la SWIG and
whatnot).
> This means that it cannot be considered a given that a program exists that
> uses all macros in the header.
A macro that is not used by a C program might be complete gibberish;
yet that program may still be well-formed.
#define ABC { ( 42 -> * "foo" ]
A C to Pascal translator which tries to treat unused macros might
needlessly choke on such a thing.
It is reasonable, nay wise, for a whole-program C to Pascal translator
to ignore C macros that are unused by the C program.
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-03 09:57 +0200
Re: Parsing partial sentences Fernando <pronesto@gmail.com> - 2017-04-04 06:05 -0700
Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-07 11:16 -0400
Re: Parsing partial sentences George Neuner <gneuner2@comcast.net> - 2017-04-07 12:59 -0400
Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-07 22:24 +0200
Re: Parsing partial sentences George Neuner <gneuner2@comcast.net> - 2017-04-10 20:22 -0400
Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-11 10:31 +0200
Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-11 19:40 +0200
Re: Parsing partial sentences George Neuner <gneuner2@comcast.net> - 2017-04-11 23:05 -0400
Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-12 13:45 +0200
Re: Parsing partial sentences Martin Ward <martin@gkc.org.uk> - 2017-04-11 10:30 +0100
Re: Parsing partial sentences Walter Banks <walter@bytecraft.com> - 2017-04-27 10:58 -0400
Re: Parsing partial sentences Kaz Kylheku <686-678-9105@kylheku.com> - 2017-04-27 19:08 +0000
Re: Parsing partial sentences rugxulo@gmail.com - 2017-04-28 16:32 -0700
Re: Parsing partial sentences Marco van de Voort <marcov@toad.stack.nl> - 2017-04-29 14:57 +0000
Re: Parsing partial sentences Kaz Kylheku <686-678-9105@kylheku.com> - 2017-04-30 16:31 +0000
Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-28 02:48 +0200
csiph-web