I do not understand the problem you linked to of finding "conflicting appointments". It does not usefully define what a "conflict" is, only saying that "An appointment is conflicting, if it conflicts with any of the previous appointments in array". It does not say what "conflict" means for appointments.

A natural assumption is that two appointments conflict if their times overlap.

The example instance of the problem gives this as input:

> Input: appointments[] = { {1, 5} {3, 7}, {2, 6}, {10, 15}, {5, 6}, {4, 100}}

The problem spoke of "appointments in array" and this is an array, so apparently {1, 5} {3, 7}, {2, 6}, {10, 15}, {5, 6}, {4, 100} are the appointments themselves. So we have 6 appointments.

So I'd guess that {1, 5} means an appointment that starts at time 1 and ends at time 5. That {4, 100} concerns me, though...if the numbers are times there is no obvious unit of time for which all of these appointments make sense.

They give this as the expected output for the above input:

  Output: Following are conflicting intervals
  [3,7] Conflicts with [1,5]
  [2,6] Conflicts with [1,5]
  [5,6] Conflicts with [3,7]
  [4,100] Conflicts with [1,5]

OK...all of those ARE conflicts under my guessed interpretation of the notation. But under that interpretation, {2, 6} should conflict with {3, 7}, and {4, 100} should conflict with everything else.

So that means my interpretation of the notation {x, y} on input meaning an appointment from time x through time y is not right.

Another idea is that {x, y} means person x and person y have an appointment together, and two appointments conflict if the same person is involved in both. Nope...that doesn't give the sample output either.

OK...maybe the sample output is wrong. So now I grabbed their code and compiled it on my Mac and ran it. It produced this output:

  Following are conflicting intervals
  [3,7] Conflicts with [-1960454340,32767]
         [2,6] Conflicts with [-1960454340,32767]
         [10,15] Conflicts with [-1960454340,32767]
         [5,6] Conflicts with [-1960454340,32767]
         [4,100] Conflicts with [-1960454340,32767]

WTF? OK...so I take it to a Linux box, and try it there, and it gives the output given at the site. Hmmm. I do see that I got a compiler warning on the Mac and not on Linux, about control reaching the end of a non-void function. The function newNode is missing a return! Putting "return temp;" at the end gets rid of the warning, and then the Mac produces the same output as Linux. (Raising the question of why gcc on my Linux box did not warn about the missing return...).

Anyway, I see that there is a function in there to determine if a pair of appointments overlap:

  // A utility function to check if given two intervals overlap
  bool doOVerlap(Interval i1, Interval i2)
  {
      if (i1.low < i2.high && i2.low < i1.high)
          return true;
      return false;
  }

OK...looking at that, it sure looks to me like it should say that {2, 6} and {3, 7} overlap. A quick test confirms that {2, 6} and {3, 7} in fact do overlap according to doOVerlap. So why isn't it figuring that out?

Putting a printout in doOVerlap to see how it is getting used:

  // A utility function to check if given two intervals overlap
  bool doOVerlap(Interval i1, Interval i2)
  {
    cout << "check " << i1.low << "," << i1.high
        << " against " << i2.low << "," << i2.high << "\n";
    if (i1.low < i2.high && i2.low < i1.high)
        return true;
    return false;
  }

changes the output to this:

  Following are conflicting intervals
  check 1,5 against 3,7
  [3,7] Conflicts with [1,5]
  check 1,5 against 2,6
  [2,6] Conflicts with [1,5]
  check 1,5 against 10,15
  check 3,7 against 10,15
  check 1,5 against 5,6
  check 3,7 against 5,6
  [5,6] Conflicts with [3,7]
  check 1,5 against 4,100
  [4,100] Conflicts with [1,5]

OK...so it is not finding that {2, 6} and {3, 7} overlap because it is never even checking them against each other.

I'll leave it to someone more curious than I to figure out what is wrong with their "solution".