I use a ROM2.4 B6 and I get this when I do a make.

act_wiz.c: In function 'copyover_recover':
act_wiz.c:5459: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result

Here is the line in question:

fscanf (fp, "%d %s %s\n", &desc, name, host);

The surrounding code is:

unlink (COPYOVER_FILE);        /* In case something crashes - doesn't prevent reading  */

    for (;;)
    {
        fscanf (fp, "%d %s %s\n", &desc, name, host);
        if (desc == -1)
            break;

        /* Write something, and check if it goes error-free */
        if (!write_to_descriptor
            (desc, "\n\rRestoring from copyover…\n\r", 0))
        {
            close (desc);        /* nope */
            continue;
        }

        d = new_descriptor ();
        d->descriptor = desc;

        d->host = str_dup (host);
        d->next = descriptor_list;
        descriptor_list = d;
        d->connected = CON_COPYOVER_RECOVER;    /* -15, so close_socket frees the char */


        /* Now, find the pfile */

Any help would be appreciated here in getting this warning out of the compile.
Thank You in advance.

It's one of the new and very annoying warnings that comes from gcc/g++ 4.4.0 and up. I haven't looked into whether or not there's a flag to silence it but the warning is safe to ignore for now.

The warning is not really safe to ignore. It's telling you that you are supposed to be paying attention to the return value of fscanf, but you aren't. The return value can tell you interesting things like you failed to read from the file, or failed to parse, etc.

It's actually very good that the compiler is starting to point out mistakes like this, because lots of strange bugs in file handling are caused by not realizing that you weren't able to do the operation you asked for. It's a little annoying if you're lazy and don't like putting in error handling, and you trust that your files will always be in the right format. But in general, you really should not be ignoring potential error codes.

Basically fscanf() returns a non-void value. So you should pay attention to what value it returns to ensure it worked properly. So, go google man fscanf and consider re-writing the line to have

var = fscanf( … ) … if( var )

or

if( fscanf( … ) )

or something to check the return value and handle it in case of an error.

so finding and fixing the issue could mean going through every function in the code…

Specifically, fscanf() is supposed to tell you how many of your arguments were actually filled. This is handy to know you actually got what you think you got, as in:

if(3 != fscanf("Foo: %s %d, %d\n", tmpstr, &tmpx, &tmpy))
    perror("Oh crap!  Invalid data here!");

So, use it… don't just hack around it to make the compiler shut up. A LOT of the errors in various Diku derivatives come from bad programming practices, and a lot of errors in the later ones are from people trying to quickly shove the warnings under the rug, rather than fixing the problems.

In this case, though, not filling 3 arguments will mean you're at the end of the list. The last entry in a copyover file is always just "-1\n"

That's assuming that your file is correctly formatted. In other words, that kind of programming – just hoping that things work – is not very robust and leads to the kind of trouble we've seen time and time again with these codebases where a tiny change in a file can bork far more than it should.

I agree in principle that ignoring this particular return value (for fscanf) is probably a bad idea, but it is very common, especially in old code.

OTOH, functions like printf also have a non-void return value – and who the hell *ever* checks the return value of printf? Sure, in principle, you should do it, because there's no guarantee you're not printing to a file on disk rather than stdout due to redirection, but I've never seen any code that checks this value.

In general, I'd say if you have no way to recover from an error, anyway (as is likely in the case of printf above), forget about checking the return value.

Otherwise, you should probably check it and implement proper error recovery.

An important exception here is the return value of malloc and any other function that returns a pointer.