Traditional code and other things.

[Carlo Bramini]

Dear friends,
I just started to use Pelles C for Win32 because I wanted to test an alternative to VisualStudio express.
While I'm giving a positive feedback, I must say that I'm having some strange messages with traditional code.
Just take this example:

Code: [Select]

int sum();

int sum(a, b)
int a;
int b;
{
    return a+b;
}

This is a perfectly legal, old style declaration, but I'm getting this message in the output window:

Code: [Select]

warning #2027: Missing prototype for 'sum'.
The second curious thing, it seems that function declarations do not inherit the class specified in the function prototypes, let's take this other example:

Code: [Select]

static int sum();

int sum(a, b)
int a;
int b;
{
    return a+b;
}

Here the compiler says:

Code: [Select]

warning #2027: Missing prototype for 'sum'.
warning #2166: Inconsistent linkage for 'sum', previously declared at C:\test\test.c(1).
Funny thing that first it says that prototype is missing and then that declaration does not match with the previously declarated prototype. 

Last thing, the compiler correctly signaled that some functions won't return because some infinite loops (warning #2134) but I perfectly know that: is there a keyword, perhaps similar to __attribute__((noreturn)) in GCC, to signal that the function won't return?

Keep up the good work!

Sincerely,

Carlo Bramini.

PS: I know that warning #2027 (but not warning #2166, that seems to be without solution) can be fixed by rewriting function declarations in the new style, but unfortunately I'm not allowed to do big changes in the source codes.

PPS: I discovered that my executables are depending of pocrt.dll: I was also wondering what the reasons are for forcing you to not use msvcrt instead.
Has been this choice taken for granting exact source compatibility between Win32 and WinMobile platforms? Have you ever evaluated the chance to add an option for linking to msvcrt too in addition to pocrt when working with win32 platform?

[Bitbeisser]

The first is a warning probably because Pelle's C is aiming to be ANSI and C99 compliant. Simplest way to eliminate this would be to add a

Code: [Select]

#pragma warn(disable 2027). That should get rid of that particular warning and avoid having to modify the code.

Personally, I would recommend to rather fix this and write proper ANSI code, after all that's around for +20 year now, nobody should write anything in the old K&R way anymore anyway...

I am not sure right off the bat about the other things, but one thing to keep in mind is that Pelle's C is a plain C compiler, while both Visual C++ and GCC are in fact C++ compilers that tolerate C code. It is fairly easy to have some C++ related issues creep into the code. I switched from the K&R style C (DeSmet C 2.x for private stuff and Lattice/Microsoft C at work) to all ANSI C back in '87 when Turbo C 1.0 came out.

Ralf

[AlexN]

I don't know where, but if I remember correct, Pelles says in the documention/help that he does not support K&R code.

[CommonTater]

I just started to use Pelles C for Win32 because I wanted to test an alternative to VisualStudio express.
While I'm giving a positive feedback, I must say that I'm having some strange messages with traditional code.

I'm sorry to say that in this case "traditional" translates to "very old" as the old style K&R declarations have been deprecated in almost every C standard since C89... almost nobody writes code in that format anymore.  Alex may be correct in that Pelle has stated he's not supporting that sourcecode format but, since nobody really uses it anymore this shouldn't be much of an issue on the grander scale.

The second curious thing, it seems that function declarations do not inherit the class specified in the function prototypes, let's take this other example:
Funny thing that first it says that prototype is missing and then that declaration does not match with the previously declarated prototype. 

Probably these are warnings issued from two different sections of the compiler... I've noticed a couple of odd combinations as well.  But in your example, the two prototypes in fact do not match.  Under C99 standards, all functions default to extern linkage... The prototype is just making a promise that "You will find this further down".  So there's no real inheritance going on... just you making a promise that, because of the default linkage, you didn't keep.
 
Also note that under C99... function() with empty parenthese indicates a function that will accept any amount or type of parameters.  Thus parameter lists in your prototype and definition must also match.  (In C99 a function that takes no parameters is written as  function(void) )

Last thing, the compiler correctly signaled that some functions won't return because some infinite loops (warning #2134) but I perfectly know that: is there a keyword, perhaps similar to __attribute__((noreturn)) in GCC, to signal that the function won't return?

The problem here is that if a function does not return, due to an infinite loop, it's very likely to lock up your application and race the CPU which can cause lots of problems in a multitasking environment like Windows... including overheating  the CPU causing a system shutdown.  The most likely outcome of infinite loops is that you don't release time slices (done at the return from each function) and could belabour the rest of the system.  It's best to avoid these kinds of situations whenever possible.

PPS: I discovered that my executables are depending of pocrt.dll: I was also wondering what the reasons are for forcing you to not use msvcrt instead.
Has been this choice taken for granting exact source compatibility between Win32 and WinMobile platforms? Have you ever evaluated the chance to add an option for linking to msvcrt too in addition to pocrt when working with win32 platform?

Yes, you can use #pragma statements to take the "no default lib" option and link to anything you like... but don't be surprised if some of your code gets broken doing this... It's one of those "don't do it unless you absolutely have to" deals. 
 
For maximum reliability, in your project options select either single threaded-lib or multi-threaded lib to statically link your projects and they won't rely upon any external dlls to run... which is probably the best way to build your code. I'm aware that Microsoft advises against static linking, generally on the premise that it allows bug fixes in the library without replacing your code.  However; this isn't a Microsoft compiler and static linking makes more sense rather than risk the pocrt.dll (or pocrt64.dll) and your program somehow getting separated.

Hope this is some help...