Re: [Mingw-users] [mingw - StupidTechiQuestions] RE: Welcome to MinGW's StupidTechiQuestions F

[Al S. <al....@sc...>]

Keith MARSHALL wrote:
>>>Read and respond to this message at: 
>>>https://sourceforge.net/forum/message.php?msg_id=2947626
>>>By: keithmarshall
>>>
>>>No, you don't.  What you *do* need is a last line which correctly 
> 
> terminates
> 
>>>with a newline character -- it may, or may not, be blank.
>>
>>I just came accross this now as well. Seems that even g++ is complaining 
> 
> 
>>about this. But I simply can't understand the reason of this 
>>requirement. Does the compiler need this newline to desambiguate 
>>something? Or is it just plain BS from the standard?
 >
 > It is a requirement of the standard, which some compilers flaunt.
 >
 > IMHO, it most certainly is *not* BS -- it is a completely worthwhile
 > sanity check.  If your last line *doesn't* end with a newline, can
 > you be certain that the file hasn't been corrupted, and that some
 > part of hasn't been chopped off the end?  Requiring that the last
 > line ends with a newline increases confidence in the integrity of
 > the file -- of course, it doesn't guarantee it, but the probability
 > of an arbitrarily truncated file actually ending with a newline is
 > fairly low.
 >
 > Regards,
 > Keith.

Look at the following.

a.h has 1 line with no newline

<start>
#define SOME_DEFINE
<end>

b.h has 1 line

<start>
int func();
<end>

test.c includes the above 2 headers

<start>
#include "a.h"
#include "b.h"

int main(int, char **)
{	
   func();
   return 0;
}
<end>

With the above, surely a prepocessed output could be (I'm not suggesting 
that such a preprocessor exists)

<start>
#define SOME_DEFINEint func();

int main(int, char **)
{	
   func();
   return 0;
}
<end>

This would not then compile.  A newline at the end of a.h would clearly 
solve the problem.

The warning should be taken as a portablity hint.

-- 
Al Slater

Technical Director
Stanton Consultancy