DDE tools quirks

With the most recent DDE 31 installed, wherever versions of the software that implies…

• It appears as if the throwback line in the compiler may be off. I’ve not done more than a simple observation at this point (and right now I’m sitting outside), but it appears as if the offset is wrong for each #include, like when it sees one it doesn’t bump the line counter. This was indeed the case for an older version of the compiler, but I’ve not tested the latest, only noted it was one out (too few), and I only have one #include in the code I was working on.
  I noticed that a similar issue regarding #warning/#error was fixed a few versions ago.

• ObjAsm is rather lacking usefulness if there is a problem in a macro. For example, if there’s a TEQP or something not supported on modern systems within a macro, then ObjAsm will throw an error at the point of the macro call, not the point of the offending instruction.
  It can be non-trivial to work out what’s upsetting the thing if there’s macros calling macros calling macros. Not my code, I hasten to add. ;)

Okay, here is a C file:

/* Test code */

//#include "kernel.h"
//#include <stdio.h>

int  main(void)
{
   Oh crap, this is line 8!
}

And here is a minimal MakeFile:

# Project:   test
# Minimal MakeFile

.SUFFIXES:   .c .s .o
CCflags = -c -depend !Depend -I,C: -throwback 
Linkflags = -aif -o $@

c_files      = o.test

libraries    = C:o.stubs

@.test:    $(c_files)
           @link $(linkflags) $(c_files) $(libraries)
           @echo Finished.

.c.o:;       cc $(ccflags) $< -o $@

# AMU will add it's own stuff below:
# Dynamic dependencies:

Load it into Zap and Sh^C to make, and you’ll see it begins:

cc -c -depend !Depend -I,C: -throwback c.test -o o.test
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.test", line 8: Error: undeclared name, inventing 'extern int Oh'
"c.test", line 8: Warning: no side effect in void context: <variable>

Delete one of the #include lines and rebuild.

cc -c -depend !Depend -I,C: -throwback c.test -o o.test
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.test", line 7: Error: undeclared name, inventing 'extern int Oh'
"c.test", line 7: Warning: no side effect in void context: <variable>

Delete the other #include line and rebuild.

cc -c -depend !Depend -I,C: -throwback c.test -o o.test
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.test", line 6: Error: undeclared name, inventing 'extern int Oh'
"c.test", line 6: Warning: no side effect in void context: <variable>

It also appears to behave in the same way if you run !CC and drag the source to that (using all the default settings).

However, it is what the French would describe using the lovely word aléatoire, as I created the following (first include commented, the second not) and dragged it to CC and it worked fine.

/* This is another test */

//#include "kernel.h"
#include <stdio.h>

int main(void)
{
  Oh no! This is line 8!
}

As far as I can see, there’s pretty much no functional difference between the two… But the second works correctly whilst the first fails, even with what is more or less the exact same setup (kernel.h commented, stdio.h referenced).
The only difference is that I used a MakeFile and AMU to build the first (though it does the same thing if using CC directly) while the second I only used CC.

Good luck!

We can rule out MakeFile/AMU.

I swapped “test” (the original filename) for “text1” (the second file, default name offered by Zap) and… it worked. Always referred to line 8.

Switched back to the first one, and it’s 6, 7, or 8 depending upon what includes are there.

<shrug>

Added a ticket, but won’t hold my breath. There are about a half billion things of greater importance…

It might be my exhaustion, but I’m struggling to see the actual problems with your examples. What is actually wrong, and what output would you expect? Everything seems to work correctly with DDE 30b…

First program:
No #includes (lines commented out), problem correctly reported as line 8.
1 include, problem reported as line 7 (off by one).
Both includes, problem reported as line 6 (off by two).

Second program: pretty much the same code doing the same thing, problem always correctly reported as being line 8.

If you’re working on a program that CC doesn’t like (and it’s a program with many lines in multiple files), then it can be somewhat annoying to have the throwback send you to the wrong places.

This isn’t a new problem, it’s been around a while, but it seems (as demonstrated) to be pot luck as to whether throwback points you at the correct place (as it will with one project) or somewhere different (as it will with another project).

It’s also why my projects these days only ever have one #include line, to a master header that does all the includes. Doing it that way means the line difference should really only be of by one.

That’s what the issue is.

I am also unable to understand the issue here. In the steps to reproduce you say that you are deleting lines and the error line decreases by one. I would expect this .

🤦 Commenting out, not deleting.

And, if you read carefully, the line number is decreasing for the more lines that would be seen as active (ie not commented out). In other words, the opposite of what you’d expect – having more lines (again, active, nothing is deleted) makes the line number of the problem go down.

The line number shouldn’t be changing.

🤦 Commenting out, not deleting.

I thought you might have meant that, but whether commented, uncommented, or deleted, the line numbers returned in throwback were always correct when I tested it.

Ridiculously long post to better explain and clarify. ;)

the line numbers returned in throwback were always correct when I tested it.

That doesn’t surprise me, given that one program works, the other fails.

I’ll do it step by step. And be aware, this is a “freshly booted” machine.

MakeFile:

# Project:   test
# Minimal MakeFile

.SUFFIXES:   .c .s .o
CCflags = -c -depend !Depend -I,C: -throwback 
Linkflags = -aif -o $@

all:       @.test @.text1

@.test:    o.test
           @link $(linkflags) o.test C:o.stubs
           @echo Finished.

@.text1:   o.text1
           @link $(linkflags) o.text1 C:o.stubs
           @echo Finished.
.c.o:;       cc $(ccflags) $< -o $@

# Dynamic dependencies:

With NO includes

Source of “test”:

/* Test code */

//#include "kernel.h"
//#include <stdio.h>

int  main(void)
{
   Oh crap, this is line 8!
}

Source of “Text1”:

/* This is another test */

//#include "kernel.h"
//#include <stdio.h>

int main(void)
{
  Oh no! This is line 8!
}

Highlights of building:

cc -c -depend !Depend -I,C: -throwback c.text1 -o o.text1
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.text1", line 8: Error: undeclared name, inventing 'extern int Oh'
"c.text1", line 8: Warning: no side effect in void context: <variable>
[...]
c.text1: 6 warnings, 5 errors, 8 serious errors
AMU: *** exit (1) ***

cc -c -depend !Depend -I,C: -throwback c.test -o o.test
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.test", line 8: Error: undeclared name, inventing 'extern int Oh'
"c.test", line 8: Warning: no side effect in void context: <variable>
[...]
c.test: 6 warnings, 5 errors, 7 serious errors
AMU: *** exit (1) ***

With ONE include

Source of “test”:

/* Test code */

//#include "kernel.h"
#include <stdio.h>

int  main(void)
{
   Oh crap, this is line 8!
}

Source of “Text1”:

/* This is another test */

//#include "kernel.h"
#include <stdio.h>

int main(void)
{
  Oh no! This is line 8!
}

Highlights of building:

cc -c -depend !Depend -I,C: -throwback c.text1 -o o.text1
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.text1", line 8: Error: undeclared name, inventing 'extern int Oh'
"c.text1", line 8: Warning: no side effect in void context: <variable>
[...]
c.text1: 6 warnings, 5 errors, 8 serious errors
AMU: *** exit (1) ***

cc -c -depend !Depend -I,C: -throwback c.test -o o.test
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.test", line 7: Error: undeclared name, inventing 'extern int Oh'
"c.test", line 7: Warning: no side effect in void context: <variable>
[...]
c.test: 6 warnings, 5 errors, 7 serious errors
AMU: *** exit (1) ***

As you can see, the “good” program remains with the duff code being reported at line 8, while the “bad” program reports line 7 now.

With BOTH includes

Source of “test”:

/* Test code */

#include "kernel.h"
#include <stdio.h>

int  main(void)
{
   Oh crap, this is line 8!
}

Source of “Text1”:

/* This is another test */

#include "kernel.h"
#include <stdio.h>

int main(void)
{
  Oh no! This is line 8!
}

Highlights of building:

cc -c -depend !Depend -I,C: -throwback c.text1 -o o.text1
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.text1", line 8: Error: undeclared name, inventing 'extern int Oh'
"c.text1", line 8: Warning: no side effect in void context: <variable>
[...]
c.text1: 6 warnings, 5 errors, 8 serious errors
AMU: *** exit (1) ***

cc -c -depend !Depend -I,C: -throwback c.test -o o.test
Norcroft RISC OS Arm C vsn 5.89 [18 Feb 2022]
"c.test", line 6: Error: undeclared name, inventing 'extern int Oh'
"c.test", line 6: Warning: no side effect in void context: <variable>
[...]
c.test: 6 warnings, 5 errors, 7 serious errors
AMU: *** exit (1) ***

And, finally, with both includes present, one can see that the “bad” program is reporting the problem as being on line 6.

• Which of the includes is used in the one-include test makes no difference.

• Adding more includes to the bad program does not reduce the count below six, as these lines are seen by the compiler if beginning “//” but seem to be invisible if beginning “#include”.

• It only seems to be triggered by #include. I added #ifdef, #define, #endif and the numbers were bumped as expected.

• Which way around they are built in the MakeFile doesn’t change anything.

• I copied “test” as “newtest” and “Text1” as “newText1” and edited the MakeFile. So it is definitely something to do with that file.

• Looking at the files in Zap using byte mode, all of the spaces are &20, all of the newlines are &0A. There’s nothing that seems out of place.

• Replacing the contents of “newtest” with the contents of “newText1” (in other words, the two files are identical) does not change anything !

• Two days, two boots, seemingly completely repeatable.

• I zipped up the code, unpacked it to a different directory. Same thing.

The code is available at https://heyrick.eu/blog/files/include.zip

The _MakeFile is the previous one (only built the one thing). The current MakeFile tries to build both in the same session (for better comparisons).

As supplied, they both have the two #include lines active, so normally both files would report a problem with line 8.
However, on my setup, “test”/“newtest” report line 6, while “Text1”/“newText1” report line 8.

You’ll notice that the content of “newtest” is identical to “newText1”. It still misreports.

I give up on trying to work out how or why this is happening.

Hmmm… maybe later I’ll try it on the main Pi, see what happens there. But I’ve not yet gotten around to updating the DDE on that machine.

Oh! [fx: lightbulb] The DDE archive is on the older Pi now, so ShareFS…

Good grief! That flew. ShareFS is clearly a lot better at pushing to a faster machine than it is pulling from it. But, it’s there and not just on my phone. That’ll make things easier.

For what it’s worth, the version of the compiler that I had on this machine prior was 5.71 (from 2014) which exhibited the same behaviour.
I noticed then that Mamie Fletcher would often report a line too many (!) ¹, while something I’m working on right now is a line behind (as in these examples), but further noticed that when patching in an extra include to try something, the discrepancy increased.

I shall now await you downloading the archive and saying “works fine here”. :-)

¹ Just tried it with the screen handling source. Yup, it’s one line ahead. Should I just find a wall and hit my head off it?

Kinda reminds me of compiling source code with DOS line endings. The error and warnings reported are always seems somewhat off. I always convert the files to Unix line endings to get rid of the problem.

Oh, DOS.

My usual there was “oh, feck arse and girls, ints are only sixteen bit on this machine”.
(the Father Ted curse because it would mean stuff fails badly in weird ways failing to handle numbers greater than the addressing range of a 6502)

That and randomly playing with memory models until the software no longer keeled over at the slightest provocation.
Oh, and in the rare times some assembler was needed, AX/AH/AL later EAX, and so on. Plus arcane rules on what they’re used for. Ugh, I play with TurboC now and then, but I’ve purged what little x86 I knew from my memory.

A DOS PC was a fairly nifty bit of kit back then (and WordPerfect 5.1 was, like, everywhere), but under the hood the early days of x86 were horrible beyond the telling of it. Shall we pop over to Aldershot for (E)ISA cards and sorting out interrupt clashes, or LOADHIGH to get stuff to fit into expanded memory (the bit above the 640K limit) in order to have as much as possible for apps? Or… Or…
<fx: sound of gunshot>

Kinda reminds me of compiling source code with DOS line endings. The error and warnings reported are always seems somewhat off. I always convert the files to Unix line endings to get rid of the problem.

Bingo. The “test” and “newtest” files have [0d] at the end of each line when viewed in SrcEdit, and they report the wrong line numbers. Deleting those characters fixes the problem.

The “test” and “newtest” files have [0d] at the end of each line when viewed in SrcEdit

<looks with WindHex on phone>

Good grief. So it does.

I wonder why that didn’t show up in Zap?
Is there an option to automatically mess with the line termination upon saving a file?

Well, there’s still an issue that seems to affect CC when the file has &0D line endings, but it’s otherwise an easy enough fix to strip ’em out.

Thank you.

:Doh!:

Commenting out, not deleting.

But maybe it comments out the [0D], which would explain the false line count when it is not commented!

Edited in response to @Rick ;-)

But maybe it comments out the [0D], which would explain the false line count.

Please reread – it’s the other way around.

When lines are commented out, everything works fine.
It’s the presence of #include that makes things go wrong.

:Doh!:

Well, I do have an excuse!

It turns out (making a copy of that file and setting it to type Data and looking at it) that if Zap spots a file with CRLF line endings, it will load the file changing the endings to RISC OS LF style and upon saving the file will put the CRLF back.
So looking at the file in byte mode, as shown, will show a regular RISC OS style file.
The only indication that this has happened is the ‘D’ in the bunch of letters to the right of the titlebar.

The Duh is quite appropriate.

if Zap spots a file with CRLF line endings, it will load the file changing the endings to RISC OS LF style and upon saving the file will put the CRLF back.

That’s… helpful :)

It’s a very useful feature when editing files from Windows, just got to look out for that D for DOS.

Multi platform development would always end up with Windows line feeds infiltrating C sources messing with the throwbacks, and with the added bonus of incorrect case of filenames and include statements. I was always running them through dos2unix and fixing up the case. At least now with git it can be set up do native linefeeds wherever you are, and be case sensitive even on Windows.

To convert to Unix line ending in Zap, IIRC you just have open the menu on the file and in File → Save options untick “DOS text file”.

Yup – but since Zap strips out the CRLF line endings upon loading a file, you first have to know that that is the problem! ;)

As pointed out, switching to byte mode to check the file is useless as this happens when loading/saving files. During the editing stage, it appears as a RISC OS style file (picture above), not a DOS style one. Easy to miss that little ‘D’.

I’ll agree with Druck, it’s a useful feature. Until it bites something else, that is.

Sadly, Zap doesn’t have built in smarts for handling files from the Beeb era, which – just to make things messier – are CR terminated. Loads of &0D in there, that appear as a little red M. Who’d have thought marking the end of a line of text would be such a complicated thing?

since Zap strips out the CRLF line endings upon loading a file, you first have to know that that is the problem! ;)

Look for the D in the title bar.

Easy to miss that little ‘D’.

Look for the D in the title bar.

Apparently it’s also easy to miss that “Easy to miss that little ‘D’” :)

At my age, I miss all sorts of things…