VBCC getting started help

[Warty]

I haven't had to muck around with code signing yet, but there are some promising looking links off that stack overflow page, thanks.

The great news is that Leffman's binaries 'just work'. ! Thanks ! I can compile and run. I suppose I'll have to find out how to fix the issue or I'll never be able to get an update, but for now, I'm able to create Amiga apps, and that's great. Thanks folks!

[phx]

Originally Posted by Warty

I suppose I'll have to find out how to fix the issue or I'll never be able to get an update

Indeed. Please keep up informed, if you find anything.


The difference is that Leffmann's LLVM is much older. But what has changed between those versions? Of course, there could be a compiler bug, but it would be quite unlikely.

[LooZee]

I guess I have a very similar problem with the ucpp part of vbcc.

I managed to compile vbccm68k and vbccppc on Windows using PellesC. A previous attempt with lcc-win32 failed because of missing/broken 64bit shift operations (in lcc-win32). PellesC successfully compiled vasm, vlink and vbcc to Win32 as well as Win64 binaries.

I get an error 261 in line -1 : missing macro name.

My command line simply is: vbccm68k test.c

It starts in main.c with a call to define_macro(). The first macro is "__VBCC__" which is defined successfully. Then comes a macro that starts with "__entry=" and it fails. Every macro with a '=' in it fails with error 261.

So I got to macro.c/define_macro(). There is this line:
*(c + n - 1) = '\n';
This will overwrite the terminating 0 with a newline character, leaving the string without '\0' terminator. Either fix it by increasing variable 'n' or change sdup() to allocate one extra byte. I noticed this when I added some debug output. However, this potential bug is not the cause of the problem.

macro.c/handle_define() generates the error when the next_token() loop doesn't find a name.

So, a macro definition like "__M68000=1" is changed to "__M68000 1\n" before being parsed, but something goes wrong from there.

[Spec-Chum]

Originally Posted by LooZee

I guess I have a very similar problem with the ucpp part of vbcc.

I managed to compile vbccm68k and vbccppc on Windows using PellesC. A previous attempt with lcc-win32 failed because of missing/broken 64bit shift operations (in lcc-win32). PellesC successfully compiled vasm, vlink and vbcc to Win32 as well as Win64 binaries.

I get an error 261 in line -1 : missing macro name.

My command line simply is: vbccm68k test.c

It starts in main.c with a call to define_macro(). The first macro is "__VBCC__" which is defined successfully. Then comes a macro that starts with "__entry=" and it fails. Every macro with a '=' in it fails with error 261.

So I got to macro.c/define_macro(). There is this line:
*(c + n - 1) = '\n';
This will overwrite the terminating 0 with a newline character, leaving the string without '\0' terminator. Either fix it by increasing variable 'n' or change sdup() to allocate one extra byte. I noticed this when I added some debug output. However, this potential bug is not the cause of the problem.

macro.c/handle_define() generates the error when the next_token() loop doesn't find a name.

So, a macro definition like "__M68000=1" is changed to "__M68000 1\n" before being parsed, but something goes wrong from there.

I build vbcc for windows with gcc 9.2.0, feel free to try this and see if this works instead.

[LooZee]

Originally Posted by Spec-Chum

I build vbcc for windows with gcc 9.2.0, feel free to try this and see if this works instead.

Thank you.


Yes, that works. Of course, I expected that. But the point is, vbcc should compile with almost any C compiler, it's meant to be easily portable. As the thread starter's case and mine have shown, there is something about vbcc that some compilers don't get right - and there must be a reason for that.


For example, different compilers give different warnings. PellesC is pretty strict and gives dozens of warnings when compiling vbcc, and they're valid warnings about potentially uninitialized variables, comparing signed with unsigned numbers, unreachable code, unused data etc.


Good code is unambiguous and there are no two ways to interpret it. I'm trying to find the ambiguity in vbcc's code.

[Spec-Chum]

Originally Posted by LooZee

Thank you.


Yes, that works. Of course, I expected that. But the point is, vbcc should compile with almost any C compiler, it's meant to be easily portable. As the thread starter's case and mine have shown, there is something about vbcc that some compilers don't get right - and there must be a reason for that.


For example, different compilers give different warnings. PellesC is pretty strict and gives dozens of warnings when compiling vbcc, and they're valid warnings about potentially uninitialized variables, comparing signed with unsigned numbers, unreachable code, unused data etc.


Good code is unambiguous and there are no two ways to interpret it. I'm trying to find the ambiguity in vbcc's code.

Ah, I see now, sorry.

[LooZee]

I compiled vbcc with Visual Studio 2019 Community Edition and it works. However it required some work because what is a warning in PellesC is considered an error in MSVC. It doesn't like potentially uninitialized variables at all. It also throws some warnings that might be interesting.

Now that I have a working build for comparison, I am trying to investigate what the problem is with the other compiler. I think it should be possible to compile an lcc-derivative with another lcc-derivative. I always prefer them over MSVC or GCC.

[phx]

Originally Posted by LooZee

So I got to macro.c/define_macro(). There is this line:
*(c + n - 1) = '\n';
This will overwrite the terminating 0 with a newline character, leaving the string without '\0' terminator.

I'm not too familar with the ucpp source, as this is probably the only part of the vbcc development environment which was not written by me or Volker.

But in this case I guess the replacement is harmless, as the lexer-state structure gets the length of that string in 'ebuf' before handle_define() is called. It doesn't need a termination character.

macro.c/handle_define() generates the error when the next_token() loop doesn't find a name.

That's strange and shouldn't happen. But somehow I remember I have seen this macro error before. Don't know in which situation and what the solution was.

Originally Posted by LooZee

But the point is, vbcc should compile with almost any C compiler, it's meant to be easily portable.

Indeed, that's our intention. A working C99-compiler should always be sufficient.

there is something about vbcc that some compilers don't get right - and there must be a reason for that.

I am usually compiling vbcc with vbcc (for AmigaOS/MorphOS) or gcc (NetBSD) and have no experience with other compilers. But we are really interested in fixing any bugs, which are discovered by using different compilers - as long as those compilers don't have a bug.

For example, different compilers give different warnings. PellesC is pretty strict and gives dozens of warnings when compiling vbcc, and they're valid warnings about potentially uninitialized variables, comparing signed with unsigned numbers, unreachable code, unused data etc.

Maybe some of those warnings should be eliminated, anyway. I like strict compilers, and gcc is certainly one of the worst, which encourages bad codeing habits in its default setting.

Good code is unambiguous and there are no two ways to interpret it. I'm trying to find the ambiguity in vbcc's code.

Absolutely! Thanks a lot.