NO

Author Topic: Why doesn't this code compile on Pelles C?  (Read 527 times)

Offline RobertSteed

  • Member
  • *
  • Posts: 1
  • Unspoilt By Progress
Why doesn't this code compile on Pelles C?
« on: March 09, 2018, 09:57:52 pm »
The code below compiles on Borland C++ (if I #include <stdio.h>), but Pelles C gives the following errors:
 expected ')' but found 'string constant'
 expected ';' but found 'string constant'
 expected ';' but found ')'
 invallid statement termination
If I remove the #ifdef #else and #endif lines, Pelles C does compile it without error. What gives?

Code: [Select]
#include <wchar.h>

int wmain(void)
{
wprintf(L"This compiler is "
#ifdef __POCC__
L"Pelles C.\n"
#else
L"not Pelles C.\n"
#endif
);
return 0;
}

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 1770
Re: Why doesn't this code compile on Pelles C?
« Reply #1 on: March 10, 2018, 02:17:22 pm »
Just remove that L from second line. ("Pelles C.\n")
May the source be with you

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1674
Re: Why doesn't this code compile on Pelles C?
« Reply #2 on: March 10, 2018, 04:02:33 pm »
The Timo workaround solves the problem and make the code apparently compatible with other C compilers (see below), but anyway this is definitely a PellesC bug.
The standard ISO/IEC 9899:2011 ยง 6.4.5 "String literals" Semantics subparagraph 5 says:
Quote
In translation phase 6, the multibyte character sequences specified by any sequence of adjacent character and identically-prefixed string literal tokens are concatenated into a single multibyte character sequence.
If any of the tokens has an encoding prefix, the resulting multibyte character sequence is treated as having the same prefix; otherwise, it is treated as a character string literal.
Whether differently-prefixed wide string literal tokens can be concatenated and, if so, the treatment of the resulting multibyte character sequence are implementation-defined (emphasis by me).

In plain words the compiler shall concatenate strings with same prefix, as in RobertSteed code, not generate an error.
The workaround, on the other hand, solves the problem, but can potentially be an UB (undefined behavior).
« Last Edit: March 10, 2018, 04:05:51 pm by frankie »