On 7/17/2013 5:31 PM, deadalnix wrote:
> On Wednesday, 17 July 2013 at 19:46:54 UTC, Walter Bright wrote:
>> On 7/17/2013 9:48 AM, deadalnix wrote:
>>> My understanding is that we only want to convert declaration to D. Can you give
>>> me an example of such corner case that would require the full frontend ?
>>
>> One example:
>>
>> --------------------------------
>> //**************************Header**********************\\
>>
>> int x;
>> --------------------------------
>>
>> Yes, this POS is real C code I got a bug report on. Note the trailing \\. Is
>> that one line splice or two? You have to get the hairy details right. I've
>> seen similar nonsense with trigraphs. I've seen metaprogramming tricks with
>> token pasting. You can't dismiss this stuff.
>
> This do not require semantic analysis.

Semantic analysis for C is trivial. The real problems are the phases of translation and the preprocessor.

On 2013-07-18 00:36, Walter Bright wrote:

> You could, but then you are left with failing to recognize:
>
>      #define FOO 3
>
> and converting it to:
>
>      enum FOO = 3;

And things like:

#if linux
short a;
#elif _WIN32 || _WIN64
int a;
#endif

Should preferably be converted to:

version (linux)
    short a;

else version (Windows)
    int a;

Other example:

#define foo(a, b) a + b

Should be converted to:

auto foo (A, B) (A a, B b) { return a + b; }

-- 
/Jacob Carlborg

On 2013-07-18 00:59, H. S. Teoh wrote:

> IOW either you don't do it at all, or you have to go all the way and
> implement a fully-functional C frontend?
>
> If so, libclang is starting to sound rather attractive...

That's what I'm telling

> Hmm. We *could* pre-preprocess the code to do this conversion first to
> pick out these #define's, then suppress the #define's we understand from
> the input to the C preprocessor. Something like this:
>
> 	bool isSimpleValue(string s) {
> 		// basically, return true if s is something compilable
> 		// when put on the right side of "enum x = ...".
> 	}
>
> 	auto pipe = spawnCPreprocessor();
> 	string[string] manifestConstants;
> 	foreach (line; inputFile.byLine()) {
> 		if (auto m=match(line, `^\s*#define\s+(\w+)\s+(.*?)\s+`))
> 		{
> 			if (isSimpleValue(m.captures[2])) {
> 				manifestConstants[m.captures[1]] =
> 					m.captures[2];
>
> 				// Suppress enums that we picked out
> 				continue;
> 			}
> 			// whatever we don't understand, hand over to
> 			// the C preprocessor
> 		}
> 		pipe.writeln(line);
> 	}
>
> Basically, whatever #define's we can understand, we handle, and anything
> else we let the C preprocessor deal with. By suppressing the #define's
> we've picked out, we force the C preprocessor to leave any reference to
> them as unexpanded identifiers, so that later on we can just generate
> the enums and the resulting code will match up correctly.

You will just end up needing to build a full C preprocessor. Just use an existing one, that is libclang.

-- 
/Jacob Carlborg

On 2013-07-17 21:40, Walter Bright wrote:

> Yes, but the front end itself must be complete. Otherwise,
> it's not really practical when you're dealing with things like the
> preprocessor - because a non-compliant front end won't even know it has
> gone off the rails.
>
> There are other issues when dealing with C .h files:
>
> 1. there may be various #define's necessary to compile it that would
> normally be supplied on the command line to the C compiler
>
> 2. there are various behavior switches (see the PR for DMD that wants to
> set the signed'ness of char types)
>
> 3. rather few .h files seem to be standard compliant C. They always rely
> on various compiler extensions
>
> These problems are not insurmountable, they just are non-trivial and
> need to be handled for a successful .h file importer.

Yes, I agree with all the above. That's why I'm using libclang. What I'm saying is that when I use a library like libclang I can choose quite freely what to convert and not convert. Example, DStep doesn't handle the preprocessor at all. But since libclang does, it can parse any header file anyway. What happens is just that the preprocessor declarations won't be translated and not end up in the translated file.

-- 
/Jacob Carlborg

On Wednesday, 17 July 2013 at 15:34:54 UTC, Jacob Carlborg wrote:
> On 2013-07-17 13:24, Paulo Pinto wrote:
>
>> Thus we are back to the compiler as library discussion.
>
> Yes, but for the C family of languages we already have a compiler as library, that is Clang.

Agreed.

I also confess that my anti-C bias got a bit softened with clang.

It does not sort out all C and C++ issues in regard with safety, but it helps bringing to C a Pascal like safety when integrated with proper tooling.

Unfortunately when using C and C++, not all compilers are like clang and it is not always easy to convince people to add extra tooling (lint and friends).

--
Paulo