I have regaled this list before with the portability problems of cpp(1). So, I won''t recapitulate them here, let alone add the new ones I''ve found. Just take it as given that cpp is a very messy corner of Unix that has been abused by legions of compiler writers for their own peculiar purposes. That being the case, DTrace is simply begging for problems if it continues to rely on whatever version of cpp the OS offers. Each Unix variant it visits will produce new, interesting bugs that will consume hours of developer time to work around. Fortunately, none of this is necessary. cpp isn''t, after all, a particularly complicated piece of code. Why not replicate the parts D needs, discard the rest, and call the result dpp? When someone uses the appropriate option, run dpp instead of cpp. And be _sure_ to let programmers call dpp separately, so that they can view how their macros are being expanded! -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
Rich Morin writes:> Fortunately, none of this is necessary. cpp isn''t, after all, > a particularly complicated piece of code. Why not replicate > the parts D needs, discard the rest, and call the result dpp?Or you can skip that step and use m4 or even Perl to generate your extremely complicated D code.> When someone uses the appropriate option, run dpp instead of > cpp. And be _sure_ to let programmers call dpp separately, so > that they can view how their macros are being expanded!I''m not wild about the idea of dpp. If it''s not compatible with cpp, then it may well be useless, because one of the key features being supported here is the ability to read in system header files to grab the needed definitions. Losing that -- and forcing people to choose between "useful features" on one hand and "compatibility" on the other -- would be a serious problem. If it _is_ compatible, then why not just make dpp be the new cpp? In other words, why not just enhance or replace cpp itself, and skip the need for a separate utility and special invocation sequence? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
At 08:13 -0500 12/18/07, James Carlson wrote:> Or you can skip that step and use m4 or even Perl to generate > your extremely complicated D code.Yes, you could. I''ve also used Erb and sh for this sort of thing. However, there are any number of D scripts out there that use cpp macro expansions, and a change would break them. Also, as you mention, there is the ability to read in system header files. All told, backward compatibility is not to be discarded lightly.> If it _is_ compatible, then why not just make dpp be the new cpp? > In other words, why not just enhance or replace cpp itself, and > skip the need for a separate utility and special invocation > sequence?First, _cpp_ isn''t compatible with cpp, as you move from OS to OS. If it were, this whole discussion would not be happening. Second, cpp has been customized, over the years, by the compiler writers, so it can''t be changed easily, even assuming cooperative attitudes: % head -11 /usr/bin/cpp #!/bin/sh # # Transitional front end to CCCP to make it behave like (Reiser) CCP: # specifies -traditional # doesn''t search gcc-include # # Please beware that this program exists only to provide legacy BSD # software access to cccp. Direct access to the C pre-processor # is deprecated; it is only supported for use by the cc(1) C # compiler. Use of cccp for anything other than C code is a bad # idea. Don''t do it. If you want a macro processor, use m4(1). In an sense, I AM asking that we "enhance or replace cpp itself", but call the result dpp, to avoid any confusion or conflict with the local variant of cpp. Finally, speaking of enhancements, I can think of some (eg, embedding macro arguments into strings) that would be useful to D, but not to C... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
Rich Morin writes:> At 08:13 -0500 12/18/07, James Carlson wrote: > > Or you can skip that step and use m4 or even Perl to generate > > your extremely complicated D code. > > Yes, you could. I''ve also used Erb and sh for this sort of thing. > However, there are any number of D scripts out there that use > cpp macro expansions, and a change would break them. Also, as > you mention, there is the ability to read in system header files. > All told, backward compatibility is not to be discarded lightly.Generating a D script with some other tool and then launching dtrace with the "-C" flag doesn''t introduce any compatibility problems that I can see. Granted, it means you''re using two different macro mechanisms, but you are using them for quite different purposes. On the other hand, swapping out cpp on a given platform for dpp (by using a different dtrace option) does introduce compatibility problems, unless dpp is itself a compatible superset of cpp on that platform -- or somehow a superset of all platforms. It sounds to me like you''re proposing that dpp is somehow tied to the usage of dtrace, rather than tied to the needs of the platform, as cpp is. That''s what makes this proposal less attractive to me. Cpp is certainly different between OSes, but that also matches the fact that the header file contents and usages are different between OSes. Whatever the preprocessor might do, it needs to process those header files correctly.> > If it _is_ compatible, then why not just make dpp be the new cpp? > > In other words, why not just enhance or replace cpp itself, and > > skip the need for a separate utility and special invocation > > sequence? > > First, _cpp_ isn''t compatible with cpp, as you move from OS to OS. > If it were, this whole discussion would not be happening.Yep; understood. It''s also reasonably true that the preprocessor feature usage within the header files themselves isn''t going to be compatible from platform to platform, and the differences in cpp match those differences. It''s unfortunate that people have chosen to "innovate" in something as basic as cpp operation, and it certainly makes D scripts less portable if they''re written to take full advantage of native cpp, but I don''t quite see how dpp allows us to escape both of the constraints: full platform native header file compatibility and enhanced operation with D.> In an sense, I AM asking that we "enhance or replace cpp itself", but > call the result dpp, to avoid any confusion or conflict with the local > variant of cpp. Finally, speaking of enhancements, I can think of some > (eg, embedding macro arguments into strings) that would be useful to D, > but not to C...Would you need that feature in dpp if D itself had string pasting? Why not fix that underlying problem rather than worrying about the preprocessor functionality? What other preprocessor features are specific to D rather than C? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
> > > Or you can skip that step and use m4 or even Perl to generate > > > your extremely complicated D code. > > > > Yes, you could. I''ve also used Erb and sh for this sort of thing. > > However, there are any number of D scripts out there that use > > cpp macro expansions, and a change would break them. Also, as > > you mention, there is the ability to read in system header files. > > All told, backward compatibility is not to be discarded lightly. > > Generating a D script with some other tool and then launching dtrace > with the "-C" flag doesn''t introduce any compatibility problems that I > can see. Granted, it means you''re using two different macro > mechanisms, but you are using them for quite different purposes. > > On the other hand, swapping out cpp on a given platform for dpp (by > using a different dtrace option) does introduce compatibility > problems, unless dpp is itself a compatible superset of cpp on that > platform -- or somehow a superset of all platforms. > > It sounds to me like you''re proposing that dpp is somehow tied to the > usage of dtrace, rather than tied to the needs of the platform, as cpp > is. That''s what makes this proposal less attractive to me. Cpp is > certainly different between OSes, but that also matches the fact that > the header file contents and usages are different between OSes. > Whatever the preprocessor might do, it needs to process those header > files correctly.Jim is correct -- the purpose of -C is to allow system header files to be consumed; the fact that it can be used in D itself is really more artifact than design. So if one would like a fancier preprocessor to allow for richer D scripts, I think the argument to make would be for better support for alternative preprocessors. For example, it would be convenient to allow preprocessors to be specified via an embedded pragma instead of exclusively on the command line. (This obviously has some slightly tricky issues that would need to be resolved, which is why we haven''t done it.) But the point is that the cpp that DTrace uses by default must be the one that is used by default on the system header files -- or as close to that cpp as possible. - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc
Peculiarly, in my rather extensive use of cpp with D, I hadn''t even _considered_ the issue of using it to import and process *.h files. Obviously, my needs are rather out of the mainstream! The way I got into all of this was that Leopard''s -C option failed me, so I started running cpp(1) as a separate step. Given that I was doing some rather baroque things with macros, being able to see the expanded form of the code was quite handy. Then, however, I ran into the facts that (a) the Leopard cpp is not by any means standard (and I had been relying on some non-standard behavior :-/) and (b) Solaris can''t be relied upon to have cpp or even cc on its $PATH. (Interested parties are welcome to peruse my workaround code in DT_Logger-0.2.tgz, as mentioned previously.) In retrospect, I''m not sure that cpp was necessarily the best choice as a preprocessor for the sorts of things I''m doing. I started out using it because it was there (and because I needed some way to make my code a bit shorter and cleaner). I may also have thought that, by choosing cpp, I was making my code easier for others to read. In any case, I intend to give the issue some serious thought, as I work further on DT_Logger. Perhaps I need a "program generator" of some sort; certainly that could make my code substantially shorter! At 10:42 -0500 12/18/07, James Carlson wrote:> Would you need that feature in dpp if D itself had string pasting?If changes to D itself are under consideration, here are a couple of wish list items: * compile-time string concatenation "foo" + "bar" => "foobar" Although, to be honest, my main motivation for wanting this is the fact that adding a %s to my printf''s for the variable name caused my programs to run out of kernel space. If Leopard had a way to increase this space, I might not have cared. * more flow-control constructs (if, case, ...) I''m not asking for looping, guys, just decent alternation... At 10:42 -0500 12/18/07, James Carlson wrote:> What other preprocessor features are specific to D rather than C?I''m not sure, but I''ll give it some thought. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development
Rich Morin writes:> At 10:42 -0500 12/18/07, James Carlson wrote: > > Would you need that feature in dpp if D itself had string pasting? > > If changes to D itself are under consideration, here are a couple of > wish list items: > > * compile-time string concatenation > > "foo" + "bar" => "foobar"A big +1 on that. D ought to be compatible with ANSI C, at least at this level.> * more flow-control constructs (if, case, ...) > > I''m not asking for looping, guys, just decent alternation...That''s been a topic before. It''s entirely possible to do this using the existing qualifiers and having duplicate probes -- they''re all processed in the order they appear. I agree that having the if/else and switch syntactic sugar would be a nice addition, though. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677