English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 19 August 2018, 05:58   #21
Warty
Registered User

 
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 45
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!
Warty is offline  
Old 21 August 2018, 16:29   #22
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,485
Quote:
Originally Posted by Warty View Post
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.
phx is offline  
Old 05 November 2019, 16:51   #23
LooZee
Registered User

 
Join Date: Nov 2016
Location: Black Forest / Germany
Posts: 9
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.
LooZee is offline  
Old 05 November 2019, 23:01   #24
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 86
Quote:
Originally Posted by LooZee View Post
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.
Attached Files
File Type: 7z bin.7z (448.8 KB, 8 views)
Spec-Chum is offline  
Old 06 November 2019, 00:16   #25
LooZee
Registered User

 
Join Date: Nov 2016
Location: Black Forest / Germany
Posts: 9
Quote:
Originally Posted by Spec-Chum View Post
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.
LooZee is offline  
Old 06 November 2019, 01:34   #26
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 86
Quote:
Originally Posted by LooZee View Post
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.
Spec-Chum is offline  
Old 06 November 2019, 04:06   #27
LooZee
Registered User

 
Join Date: Nov 2016
Location: Black Forest / Germany
Posts: 9
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.
LooZee is offline  
Old 07 November 2019, 23:12   #28
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,485
Quote:
Originally Posted by LooZee View Post
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.

Quote:
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.

Quote:
Originally Posted by LooZee View Post
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.

Quote:
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.

Quote:
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.

Quote:
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.
phx is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Need a little help getting started... stevecole New to Emulation or Amiga scene 20 18 April 2009 22:30
Need help gettin started guybhoy New to Emulation or Amiga scene 12 16 February 2008 07:09
Getting started!! thequeenfan New to Emulation or Amiga scene 14 19 December 2003 00:46
Just getting started scot_pete New to Emulation or Amiga scene 6 24 June 2002 20:14
Getting started again The Shadow New to Emulation or Amiga scene 1 07 April 2002 23:42

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.06959 seconds with 16 queries