Comparing source files

[DiTBho]

That's an interesting approach, although obviously quite different. As I understand it, you could have two "completely" different source files, if the corresponding ASTs are the same, it would show no difference.

it only works with "my-c" sources, refuses "c" sources, and the first thing it chckes is the "level", so it can only compares

Code: [Select]

{
   { source0:level0, source1:level0 } <--------- this is 90% compatible with C/89, but not 100%
   { source0:level1, source1:level1 }
   { source0:level2, source1:level2 }
   { source0:level3, source1:level3 }
}


It would then miss any code style difference, comments, etc.

Yup, this is a defect. There must be Only one style.

To reduce the things I have to develop, I forced only one style, which is imposed to the user, and whatever the user writes (spaces, tabs, personal indentation), the tool always re-formats the source with the imposed style.

Comments are special-cases. A comment is recognized as "token_comment", managed as block, and its context is handled by the traditional diff algorithm, including CR.

Tabs are not allowed, and automatically converted into 4 spaces, as well as CR LF are automatically converted into CR LF (DOS --> Unix)
So, comments keep CRs LFs, you can see differences between the same comment, e.g. { typos fixed, more details added &| removed, ... } in two different sources.

edit:
fixed

[cfbsoftware]

CR LF are automatically converted into CR (DOS --> Unix)

Shouldn't that be:

CR LF are automatically converted into LF (DOS --> Unix)

[Nominal Animal]

Yup.  The four newline conventions, listed by the most well-known OSes that used them:

• LF ("\n"): Unix, BSDs, Linux, Android, OS X.
   
• CR ("\r"): Old Mac OS prior to X.
   
• CR LF ("\r\n"): DOS, Windows.
   
• LF CR ("\n\r"): An error, but invisible on most systems, behaving like a normal newline, and is thus occasionally encountered in the wild.  Can also occur in Unix/BSD/Linux/etc. systems when using tty devices (terminals, serial ports) with termios INLCR and ICRNL set on input with the other side using CR LF newlines.

My own conception for "universal newlines" is supporting any mix of the four, optionally with NUL ("\0") also considered a newline.

[Picuino]

+1 for Beyond Compare.
There are versions for Win, Mac and Linux, and with trial versions.
https://www.scootersoftware.com/download

[SiliconWizard]

Yup.  The four newline conventions, listed by the most well-known OSes that used them:

• LF ("\n"): Unix, BSDs, Linux, Android, OS X.
   
• CR ("\r"): Old Mac OS prior to X.
   
• CR LF ("\r\n"): DOS, Windows.
   
• LF CR ("\n\r"): An error, but invisible on most systems, behaving like a normal newline, and is thus occasionally encountered in the wild.  Can also occur in Unix/BSD/Linux/etc. systems when using tty devices (terminals, serial ports) with termios INLCR and ICRNL set on input with the other side using CR LF newlines.

My own conception for "universal newlines" is supporting any mix of the four, optionally with NUL ("\0") also considered a newline.

Yes.

[DiTBho]

Fixed 

LF CR ("\n\r"): An error, but invisible on most systems, behaving like a normal newline, and is thus occasionally encountered in the wild.  Can also occur in Unix/BSD/Linux/etc. systems when using tty devices (terminals, serial ports) with termios INLCR and ICRNL set on input with the other side using CR LF newlines.

umm, speaking of being invisible, I never noticed it on the DEC VT525(1994) hardware terminal with /usr/bin/screen on /dev/ttyS0
it shouldn't have worked 

[Nominal Animal]

LFCR "\n\r" works on Unix, BSD/Linux/etc., and VT terminals because while LF "\n" is a full newline, CR "\r" only returns the cursor to the beginning of the current line.  Thus, the effect of LF CR "\n\r" is exactly the same as LF "\n" only.  Invisible, like I said!

This is often exploited by POSIXy command-line programs that report progress using e.g.
    fprintf(stderr, "\r%.2f%% done", 100.0*i/n);
    fflush(stderr);  // Optional; normally/by default, this is not needed
followed by
    fprintf(stderr, "\r                   \r"); // or "\r\022[K"
    fflush(stderr);  // Optional; normally/by default, this is not needed
where "\033[K" (or "\e[K" where \e represents ASCII/ISO Latin/UTF-8 code 27 = 0x1B = ESC) is the ANSI Control Sequence for clearing the current line from the current cursor position to the end of the line without moving the cursor, when the maximum number of characters needed to "erase" the progress output is unknown.

If the progress is reported to standard output, or there is more information printed to standard error that may have been redirected to a file, often the followup is just a simple fprintf(stderr, "\n"); or fprintf(stderr, "\rCompleted.     \n");, as that way the progress information will look like a single line in the file, but won't otherwise mess up the output.

[dobsonr741]

Araxis Merge. They are in this business was for a long time, and for a reason.

[bobcat2000]

I, too, use Notepad++ with the compare plugin if you just want to look for differences.  It will do its best to line up the codes and color codes the differences.  Open the 1st file, open the 2nd file, and then click the compare button.  Nothing simpler than that.

Unless you want to merge the 2 files. I am using DiffMerge for that.

[westfw]

CR LF ("\r\n"): DOS, Windows.

Also most old DEC OSes, and "NVT ASCII", supposedly used by many internet protocols (telnet, specifically.  But also SMTP, etc.)
This means you also sometimes see CR NUL, which is supposedly a "bare CR" in NVT ASCII.