If you would like to have a comment begin a generated .h file, the XPIDL compiler ignores starting %{C++ block. For example, if your .idl file starts: %{C++ /* * I want this comment in the .h file! * %} . . . That block does not appear in .h file.

Thanks for catching this! One of those subtle bugs I thought noone would notice... Patrick Beard pointed out a problem with our %{C++ code a few days ago (only handles \n, which isn't xp) - I'll try to fix this at the same time. Mike

If you're going to fix fiddle with this then you might look into why blank lines get stripped

Yep, line handling is messed up in multiple ways, and I'm planning to look at all of them.

John Fairhurst notes that this is also broken in another way on OS/2: > I (thought I) got the xpidl compiler working fine on OS/2 about a month > ago. A problem showed up the other day when it was used 'in anger' for > the first time. > > The symptom was that lines between %{C++ and %} were not being emitted in > 'header' mode. I traced this to a line in xpidl_header.h which read: > > if (strcmp(IDL_CODEFRAG(state->tree).desc, "C++")) > > Turned out that whenever this should have been true, the string at 'desc' > was actually "C++\r". So I guess this comes from OS/2 using \r\n to > separate lines, and the lexer rule in libIDL: > > <XPIDL>^%\{.* > > ...swallowing up characters up to and including the \r in the line. > > So, does anyone have any idea what bit of code I should change to fix > this? Clearly hacking xpidl_header.c is a quick solution (and what I've > done for now), but doesn't seem right -- who should be ignoring the '\r's? > Doesn't windows use \r\n? Thanks for any pointers.

Adding John Fairhurst to the cc: list.

Postponing from m6, because: - There's an easy workaround (put a newline before the %{C++ block) - Shaver has promised me a rewrite of xpidl_idl.c, which is currently a tangle of gotos and state. Hm. John Fairhurst's complaint looks like it could be a problem with libIDL, though that would be strage given that libIDL seems to work OK on windows, where lines also end with \r\n. CCing Andrew Veliath as well.

Solved my problem -- a strange compiler option was making fopen() always use binary mode. Purely a platform thing; xpidl not at fault...

Adding mang@subcarrier.org to cc list

Mike 3, what's the status of the xpidl_idl.c update? This should get folded in with that. By m7? Mike 1

Right now fixing line numbers gets priority since it's more annoying. m7 may get pushed back by a week, in which case this will be fixed in time. Is John Fairhurst's problem solved? (mjf35@cam.ac.uk == John Fairhurst?)

Sounds like the right priorities. John Fairhurst's problem is solved, I think. He's mjf35@.

Should be fixed by my xpidl_idl.c landing, and my simple tests show that it is. If not, assign it to me when you re-open.

Marking verified.