Pelles C forum

Pelles C => Announcements => Topic started by: Pelle on July 23, 2021, 01:31:22 PM

Title: Release Candidate for version 11.00 is now available
Post by: Pelle on July 23, 2021, 01:31:22 PM
http://www.smorgasbordet.com/pellesc/download.htm
Title: Re: Release Candidate for version 11.00 is now available
Post by: John Z on July 23, 2021, 02:33:02 PM
Wow amazing! Thank you Pelle.  Congratulations too.

John Z
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 23, 2021, 02:58:20 PM
Great news! Thanks Pelle. I'm going to test it.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Grincheux on July 23, 2021, 04:11:30 PM
Thank You for this great jo Mr Pelle.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 23, 2021, 04:39:57 PM
Well, there are several more warnings during the compilation process, and some of them helped me to trace down a couple of tricky bugs. So, thanks Pelle again!

Regarding to the warnings, when I free an allocated buffer, and the same buffer is also freed elsewhere, the compiler shows the following:
Code: [Select]
void foo(void)
{
  char *buffer = malloc(32);
  if (buffer == NULL) return;
  buffer[0] = '\0';

  DWORD dwRet = GetLastError();           <-- Just an example. This is not important.
  if (dwRet)
  {
        free(buffer);
        return;
  }

  free(buffer);                           <-- warning #2116: Local 'buffer' is used without being initialized (or using a dangling value).
}

To 'fix' the warning, I have to modify the code as following:
Code: [Select]
void foo(void)
{

  char *buffer = malloc(32);
  if (buffer == NULL) return;
  buffer[0] = '\0';

  DWORD dwRet = GetLastError();
  if (dwRet)
  {
        free(buffer); buffer = NULL;      <-- 'fix'
        return;
  }

  free(buffer);                           <-- no more warning
}
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 23, 2021, 05:09:21 PM
Regarding to the warnings, when I free an allocated buffer, and the same buffer is also freed elsewhere, the compiler shows the following:
<snip>
Yes, I'm aware of this - that's why I called it "aggressive".
I have seen this for a few cases in my own code, and my solution was similar to yours.

It's somewhat tricky to separate the good warnings from the silly ones - maybe this can be improved over time... (I really like the good warnings, even if there is a little noise...)
Title: Re: Release Candidate for version 11.00 is now available
Post by: John Z on July 23, 2021, 06:07:06 PM
It ay be 'old style' but a simple change 'fixes' it.
Code: [Select]
void foo(void)
{char *buffer = NULL;

  buffer = malloc(32);
  if (buffer == NULL) return;
  buffer[0] = '\0';

  DWORD dwRet = GetLastError();
  if (dwRet)
  {
        free(buffer);                     //<-- no 'fix' needed
        return;
  }

  free(buffer);                           //<-- no more warning
}

John Z
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 23, 2021, 09:34:30 PM
Yes, I'm aware of this - that's why I called it "aggressive".
I have seen this for a few cases in my own code, and my solution was similar to yours.

It's somewhat tricky to separate the good warnings from the silly ones - maybe this can be improved over time... (I really like the good warnings, even if there is a little noise...)

I agree with you. As I said, thanks to the 'noise' of this version, I found out a couple of tricky bugs in my projects.

It ay be 'old style' but a simple change 'fixes' it.
<snip>

Hi John. I tried your same solution prior to posting the 'fix', but that not 'solve' it. The warning is still there.
Title: Re: Release Candidate for version 11.00 is now available
Post by: John Z on July 23, 2021, 10:28:14 PM
Hi John. I tried your same solution prior to posting the 'fix', but that not 'solve' it. The warning is still there.

Really - that makes it a bit more interesting.  I did not post it without testing and seeing a good result.
I just now went back and tested again in two different programs and get no errors with Level 2 warnings enabled.
lt also compiled w/o error under C99, C11, and C17.

I always want to use the most robust checking, am I missing some higher level checking setting?

Thanks Marco,

John Z
Title: Re: Release Candidate for version 11.00 is now available
Post by: TimoVJL on July 24, 2021, 07:21:55 AM
Thanks Pelle for a new version to test.
Title: Re: Release Candidate for version 11.00 is now available
Post by: MrBcx on July 24, 2021, 08:15:58 AM
Thank you Pelle ... quite an impressive list of improvements over v10.

Also, the following did not go unnoticed, although I was hoping that it be named POBeautify   :D

"Added simple command-line driver for the IDE source code formatter DLL (cformat.dll), cleverly named cformat.exe."
Title: Re: Release Candidate for version 11.00 is now available
Post by: algernon_77 on July 24, 2021, 08:23:29 AM
Thanks for the new version!

It builds all my projects, minus one. It stops with "fatal error: Internal error: get_rule_number()". Projects builds fine under v10. OS is Win10 Pro 20H2, in a virtual machine.
I attach the zipped project.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 24, 2021, 08:42:43 AM
Also, the following did not go unnoticed, although I was hoping that it be named POBeautify   :D
Nah, that's more than 8 characters... can't have that...  ;D
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 24, 2021, 08:43:41 AM
It builds all my projects, minus one. It stops with "fatal error: Internal error: get_rule_number()". Projects builds fine under v10. OS is Win10 Pro 20H2, in a virtual machine.
I will have a look..
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 24, 2021, 11:04:31 AM
It builds all my projects, minus one. It stops with "fatal error: Internal error: get_rule_number()". Projects builds fine under v10. OS is Win10 Pro 20H2, in a virtual machine.
I will have a look..
OK, had a look... special handling of infinite loop ( "while (TRUE)" ) inside a __try - __except block (leading to an unexpected abnormal CFG edge).

Can you please check that this new pocc.exe works for you too?
www.smorgasbordet.com/pellesc/1100/tmp/pocc_11_00_1.zip (http://www.smorgasbordet.com/pellesc/1100/tmp/pocc_11_00_1.zip)
Title: Re: Release Candidate for version 11.00 is now available
Post by: algernon_77 on July 24, 2021, 12:32:49 PM
Happy to report that all seems to be ok now  :)
Thanks!
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 24, 2021, 12:50:35 PM
Really - that makes it a bit more interesting.  I did not post it without testing and seeing a good result.
That is very interesting indeed. I have several functions showing that warning. I applied your same solution to each of them, but the warning is still there. The following is the command line I use to compile my projects (where '%1' is the name of the file to compile):

Code: [Select]
pocc -W2 -Gz -Ze -Zx -Tx64-coff -D_WIN32_WINNT=0x0600 %1

Marco
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 24, 2021, 03:41:21 PM
Hi Pelle. In my projects I have several structure variables initialized to zero by using '= {0}'. For just one of them, the compiler shows the following warning:
Code: [Select]
STORAGE_PROPERTY_QUERY query = {0};    <-- warning #2272: '0' is not a member of 'STORAGE_PROPERTY_ID (aka enum _STORAGE_PROPERTY_ID)'

In that case (and just in that case), I have to use the 'memset' function to zero out the structure.
Since the warning is shown just for that variable structure, I'm wondering if it's an issue or just a warning to be ignored.
Title: Re: Release Candidate for version 11.00 is now available
Post by: John Z on July 24, 2021, 03:43:23 PM
Thanks, that helped!

I found that using any Compiler Optimization setting (speed or size) with or without "Extra optimizations" and the 2116 warning disappears.  So my 'fix' was invalid .... sorry about that.   Mystery solved though  :)

John Z
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 24, 2021, 03:52:00 PM
Happy to report that all seems to be ok now  :)
Thanks!
Very good - thanks!
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 24, 2021, 04:04:30 PM
Hi Pelle. In my projects I have several structure variables initialized to zero by using '= {0}'. For just one of them, the compiler shows the following warning:
Code: [Select]
STORAGE_PROPERTY_QUERY query = {0};    <-- warning #2272: '0' is not a member of 'STORAGE_PROPERTY_ID (aka enum _STORAGE_PROPERTY_ID)'

In that case (and just in that case), I have to use the 'memset' function to zero out the structure.
Since the warning is shown just for that variable structure, I'm wondering if it's an issue or just a warning to be ignored.
That 0 will be seen as an initializer of the first element of STORAGE_PROPERTY_QUERY, which happens to be an enumeration. The warning is meant to persuade you to use a proper enumerator name rather than some (random) integer...

...but..

...this enumeration seems to have an enumerator (StorageDeviceProperty) with the value 0, and since the intializer idiom {0} is common, it would be nice to shut up the compiler in this case.
My problem is that I don't want to call this check from numerous places in the compiler, but at it's current (central) location it's far from where initializers are otherwise handled (and I don't really need yet another flag). I have to think about this...
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 24, 2021, 04:29:54 PM
<snip>
Mystery solved though  :)

Yep!  :)
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 24, 2021, 04:32:06 PM
<snip>
I have to think about this...

Thanks for your explanation, Pelle.

Marco
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 24, 2021, 05:20:28 PM
Good job Pelle!  ;)
Title: Re: Release Candidate for version 11.00 is now available
Post by: Grincheux on July 25, 2021, 12:11:50 PM
Vacation now Mr Pelle.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 25, 2021, 04:03:25 PM
I have a bunch of functions using the 'realloc' function. After a pointer is passed to the 'realloc' function, the compiler shows several warnings. Please, take a look at the following example:

Code: [Select]
void foo(void)
{
  char *buffer = malloc(32);
  if (buffer == NULL) return;
  buffer[0] = '\0';

  char *newbuffer = realloc(buffer, 64);
  if (newbuffer == NULL)
  {

      if (buffer)                     <-- 2 warnings here. warning #2116: Local 'buffer' is used without being initialized (or using a dangling value).
      {                                                    warning #2130: Result of comparison is constant.

          free(buffer);               <-- 2 warnings here. warning #2807: Attempt to free a non-heap object.
                                                           warning #2116: Local 'buffer' is used without being initialized (or using a dangling value).
         
         
          buffer = NULL;

      }

      return;

  }

  buffer = newbuffer; newbuffer = NULL;
  free(buffer); buffer = NULL;
}

I suspect that the compiler complains about how the 'buffer' pointer is passed to the 'realloc' function.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 25, 2021, 05:02:24 PM
I suspect that the compiler complains about how the 'buffer' pointer is passed to the 'realloc' function.
Yes, and I think this is the only really problematic case for the generic __declspec(release( )) annotation in the C runtime. If realloc() succeeds you shouldn't touch buffer, but if realloc() fails you want to clean up. If f.e. fclose() fails, it's unlikely anyone would call fclose() again to see if it works any better...

The choices I can think of are:
1) Do something special for realloc() - but I hate special cases, they usually come back and bite you in the end.
2) Remove the __declspec(release( )) annotation from realloc() - this will obviously shut up all the noise, but also drop any useful warnings...

What do you think?
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 25, 2021, 10:23:28 PM
The choices I can think of are:
1) Do something special for realloc() - but I hate special cases, they usually come back and bite you in the end.
2) Remove the __declspec(release( )) annotation from realloc() - this will obviously shut up all the noise, but also drop any useful warnings...

What do you think?

If I had to choose between your two solutions, I'd definitely choose the first one. I also hate to manage special cases, but I consider the new verbosity level of the compiler extremely useful and it would be a pity to have to give up the warnings. That would be like taking a step back (whereas this new version is several steps ahead).
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 26, 2021, 10:05:28 PM
It seems that replace won't work if the 'with' field is empty.
Practically is impossible to use the replace to remove something.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Vortex on July 27, 2021, 04:34:27 PM
Hi Pelle,

Thanks for the new release. Now, Poasm works as expected. This one works :

Code: [Select]
push @CatStr(<">,stackval,<">)
Thanks for the fix mentioned in the Macro assembler section of the Major changes page.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 28, 2021, 11:47:24 AM
If I had to choose between your two solutions, I'd definitely choose the first one.
Yeah, this is probably better. I will see what I can do...
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 28, 2021, 11:51:09 AM
It seems that replace won't work if the 'with' field is empty.
Practically is impossible to use the replace to remove something.
Yes, but nothing new AFAICT - "MyGetWindowText()" returns NULL for an empty string, which is fine in any other context...
I will see what I can do...
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 28, 2021, 11:52:45 AM
Thanks for the new release. Now, Poasm works as expected.
Very good - thanks!
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 28, 2021, 02:06:32 PM
It seems that replace won't work if the 'with' field is empty.
Practically is impossible to use the replace to remove something.
Yes, but nothing new AFAICT - "MyGetWindowText()" returns NULL for an empty string, which is fine in any other context...
I will see what I can do...
Thanks Pelle. Now I'm not really sure, but I'm confident enough that it worked in the other versions, and I used it to remove parts (replace with nothing).
I work forward for regular expression replace too..  ;)
Really impressive work on semantics...  :o
The warnings on level 2 are really really helpful to avoid some stupid errors that makes big troubles being impossible to find.
I really appreciate the warning on variables shadowing when a redeclaration happens in a different scope. One of the hardest bugs to handle.  :-[
Really a great job. ;)

P.S. When you have time please spend a little of it investigating the debugger. Under I don't really know conditions, won't start and shows a memory exception error. Modifying the sources slightly, or sometimes rebuilding (sometime requires hand removal of previously generated objects) and recompiling hopefully it works. This is very frustrating when debugging windows code, with a bug and the debugger not working. Thanks in advance.  :(
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 28, 2021, 03:39:20 PM
Now I'm not really sure, but I'm confident enough that it worked in the other versions, and I used it to remove parts (replace with nothing).
I don't have an older version installed right now. Looking through the version control history, it looks like I did some refactoring to replace buffers using an artificial maximum limit with dynamic memory. Anyway, should be fixed now.

P.S. When you have time please spend a little of it investigating the debugger. Under I don't really know conditions, won't start and shows a memory exception error. Modifying the sources slightly, or sometimes rebuilding (sometime requires hand removal of previously generated objects) and recompiling hopefully it works. This is very frustrating when debugging windows code, with a bug and the debugger not working. Thanks in advance.  :(
Well, as they say, "it works here". I really need more info, since the debugger code is huge. I need to know a bit more about what I'm looking for...  :(

EDIT: Not sure it matters, but if you have any add-ins running you could always try to disable them for a little while...
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 28, 2021, 03:50:44 PM
If I had to choose between your two solutions, I'd definitely choose the first one. I also hate to manage special cases, but I consider the new verbosity level of the compiler extremely useful and it would be a pity to have to give up the warnings. That would be like taking a step back (whereas this new version is several steps ahead).
After thinking some more about this, I decided to remove the release annotation from realloc(). This is too much of a special case.

The most common mistake with realloc() is probably to use
Code: [Select]
ptr = realloc(ptr, ...)
rather than

Code: [Select]
newptr = realloc(ptr, ...)
if (!newptr) {
  free(ptr);
  /* error handling */
} else {
  ptr = newptr;
}

There is already another warning for the first form. If you use the second form, you probably know what to do anyway and it seems unlikely that any convoluted special case will trigger much (if ever).


Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 28, 2021, 06:09:50 PM
P.S. When you have time please spend a little of it investigating the debugger. Under I don't really know conditions, won't start and shows a memory exception error. Modifying the sources slightly, or sometimes rebuilding (sometime requires hand removal of previously generated objects) and recompiling hopefully it works. This is very frustrating when debugging windows code, with a bug and the debugger not working. Thanks in advance.  :(
Well, as they say, "it works here". I really need more info, since the debugger code is huge. I need to know a bit more about what I'm looking for...  :(

EDIT: Not sure it matters, but if you have any add-ins running you could always try to disable them for a little while...
Thanks Pelle. Unfortunately myself don't know what influence the misbehavior. It seems to happen and disappear by itself. I have tried many things, disable addins, close and reopen the IDE, reboot the system, recompile, ....
But I don't know what really change the behavior...  :-\
What I can suppose is that something in the initialization of debugger fails depending on a very special construct, maybe a line number reference inexistend due to optimization or code reducing or the like. Even if I compile with no optimizations...  :(
Basically the error is a memory violation, the debugger try to access an invalid object...
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 28, 2021, 07:34:22 PM
But I don't know what really change the behavior...  :-\
- What kind of error indication do you actually get? A message? Saying what?
- Did this start with version 11.00, or with a previous version? (If older: which one? do you know?)
- Is this happening with multiple projects?
- Does this happen on the first debugging session too, or only after debugging + edit/compile + debugging...?
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 28, 2021, 09:59:26 PM
The most common mistake with realloc() is probably to use
Code: [Select]
ptr = realloc(ptr, ...)
Yes. That's just what I was thinking when I replied. Anyway, on second thoughts, your reasoning makes sense :)
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 28, 2021, 10:52:18 PM
- What kind of error indication do you actually get? A message? Saying what?
- Did this start with version 11.00, or with a previous version? (If older: which one? do you know?)
- Is this happening with multiple projects?
- Does this happen on the first debugging session too, or only after debugging + edit/compile + debugging...?
First of all, maybe I haven't specified yet, the debugger doesn't crash after start, simply doesn't start at all showing a task dialog with the error.
The error on the task dialog is the classic 0xC0000005 for memory violation, followed by the memory address where failure happen. Up to now it not happened again. If I get it again I'll post the image of the error message.
This error happened even with previous versions. No one specific. On a specific really big console project I had to use VS for debugging. It never worked. Compiler was version 8.00/9.00.
On that very project I was never able to make debugger work.
Not happens on specific type of projects, I could affirm that is more frequent when multiple threads are used in the code.
It could happen on the first run, but is improbable that the first versions of the code is so much complicated to trigger the problem.
The last time it happened on a window project. The project was in development with the version 10.00. Still very simple to make any trouble with the previous version I suppose, then I installed the new version. The new IDE updated the project file, then I continued the development.
One strange thing I noted when the problem started is that the project clean, when accessed in a workspace, didn't cancelled all files, but just the resource file an one object. I tried opening the project by itself without the workspace and the behavior was the same.
Anyway I didn't give importance to that anomalies because the compilation worked as usual on modified files and the problem appeared and disappeared between recompilation, cleaning, and other uncorrelated actions: close and reopen IDE, restart the system, start IDE as administrator and so on.
At the end I opened the object files location and manually removed the files operating a fully manual cleaning.
From that on Don't remember that the problem happened again, and also the project cleaning seems to clean all objects now.
I didn't considered this relevant because I was habit to the apparently casual problem frequency.
I can't say much more. I know that is too few information to search for the problem, moreover it seems that nobody else met this problem, so maybe there is something on my machine that interferes with the debugger.
I'm using Norton antivirus, that always complain about PellesC and the programs I compile, maybe the problem can come from it (even if I disabled the development directory). The antivirus, for the first time as I can remember, complained on the installation of the PellesC V11.00, and I had to force the installation.
Anyway thanks.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 29, 2021, 11:05:13 AM
First of all, maybe I haven't specified yet, the debugger doesn't crash after start, simply doesn't start at all showing a task dialog with the error.
<snip>

Thanks for the info, I understand the problem better now.

Well... it's easy to blame some anti-virus program, they have caused me many problems over the years, but without any proof this seems premature/unfair. I switched to Microsoft Defender a few years ago, mostly in the hope that it would reduce the noise from weird "side effects". Hard to say how much it helped. Maybe some.

From starting the debugger ("F5") to entering the debugger loop, with it's own try-except statement and a different error message, not that much interesting is happening. The executable is opened and a checked for the presence of debug info and the name of the entry-point. This is also guarded by a try-except statement. Well, I can at least double-check this path of the code...
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 29, 2021, 12:39:57 PM
As I said, I love the new verbosity level of this version. One of the new warnings is issued when an expression is with no effect. For example:
Code: [Select]
DWORD dwErr = GetLastError();
if (dwErr == 0)       <-- warning #2046: Expression with no effect removed.
{
}

In the following example, however, the warning is not shown:
Code: [Select]
DWORD dwErr=0;
if (GetLastError() == 0)       <-- No warning here.
{
}
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 29, 2021, 01:25:46 PM
As I said, I love the new verbosity level of this version. One of the new warnings is issued when an expression is with no effect. For example:
Code: [Select]
DWORD dwErr = GetLastError();
if (dwErr == 0)       <-- warning #2046: Expression with no effect removed.
{
}

In the following example, however, the warning is not shown:
Code: [Select]
DWORD dwErr=0;
if (GetLastError() == 0)       <-- No warning here.
{
}
Maybe because of a side effect that could be expected from the execution of GetLastError().
In the first case it is executed anyway, and only the 'if' part removed.
It seems the correct behavior to me.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 29, 2021, 02:39:44 PM
Maybe because of a side effect that could be expected from the execution of GetLastError().
Hi frankie. I used the 'GetLastError()' function just as an example. If I use any other function that returns a value (also a function created by me), the warning is not shown. I might have misunderstood the meaning of that warning, but I think it means something like "Hey, here there is dead code!", and both examples produce an irrelevant operation between '{' and '}' (in both cases, there is no code between curly brackets, and so the 'if' statements are useless). Just another example:
Code: [Select]
size_t n = lstrlen("foo");
if (n) ;                  <-- warning #2046: Expression with no effect removed.
if (lstrlen("foo")) ;     <-- no warning.
Title: Re: Release Candidate for version 11.00 is now available
Post by: John Z on July 29, 2021, 03:23:33 PM
I don't have an older version installed right now. Looking through the version control history, it looks like I did some refactoring to replace buffers using an artificial maximum limit with dynamic memory. Anyway, should be fixed now.

Thanks for the fix.  If needed I have version 9, 10 and 11 all running - I can test for things if needed.
Both 9 and 10 did work with a NULL or 'empty' replacement string.

John Z
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 29, 2021, 04:16:40 PM
As I said, I love the new verbosity level of this version. One of the new warnings is issued when an expression is with no effect. For example:
Code: [Select]
DWORD dwErr = GetLastError();
if (dwErr == 0)       <-- warning #2046: Expression with no effect removed.
{
}

In the following example, however, the warning is not shown:
Code: [Select]
DWORD dwErr=0;
if (GetLastError() == 0)       <-- No warning here.
{
}

The second case just compares a temporary variable with a constant, which the warning filter function will classify as "not important enough to warn about". This reduces the warning noise. The first case compares a user-defined variable, which is classified as "important enough".
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 29, 2021, 04:58:51 PM
The second case just compares a temporary variable with a constant, which the warning filter function will classify as "not important enough to warn about". This reduces the warning noise. The first case compares a user-defined variable, which is classified as "important enough".
A thorough explanation, as usual. Thanks!
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 30, 2021, 11:33:55 AM
Both 9 and 10 did work with a NULL or 'empty' replacement string.
Thanks John. I was almost sure that it worked before.
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 30, 2021, 11:43:56 AM
The second case just compares a temporary variable with a constant, which the warning filter function will classify as "not important enough to warn about". This reduces the warning noise. The first case compares a user-defined variable, which is classified as "important enough".
Maybe I'm slow, but I didn't understood. It is clear that removing a comparison with a temporary, and not anyway visible, variable isn't worth of warning because it will be completely transparent to the user, but the execution of whichever function and, consequently, all its eventual side effects (that couldn't be known to the compiler) shouldn't be removed.
If I well understood the filtering happens on the temporary variable originated from the return value of the function after it has been called. So the function is executed anyway, with all its eventual side effects, always and never removed.
Is this correct?
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 30, 2021, 05:29:35 PM
Consider the following snippet:
Code: [Select]
bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
{
free(regs);
return false;
}
if (!check(regs))
{
free(regs); //<--  warning #2116: Local 'regs' is used without being initialized (or using a dangling value).
return false;
}
return true;
}
The compiler doesn't consider that after releasing memory no more code will be executed in this function.
In more complicate functions the noise of warnings would be considerable, unless the code is modified, possibly making it less readable, to avoid the warning.
The workaround, to avoid very complicate if-else nesting is:
Code: [Select]
bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
goto error;

if (!check(regs))
goto error;
return true;
error:
free(regs);
return false;
}
It would be nice if the compiler can consider the end of function (the return) also on variables changes.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 30, 2021, 09:00:29 PM
The second case just compares a temporary variable with a constant, which the warning filter function will classify as "not important enough to warn about". This reduces the warning noise. The first case compares a user-defined variable, which is classified as "important enough".
Maybe I'm slow, but I didn't understood. It is clear that removing a comparison with a temporary, and not anyway visible, variable isn't worth of warning because it will be completely transparent to the user, but the execution of whichever function and, consequently, all its eventual side effects (that couldn't be known to the compiler) shouldn't be removed.
If I well understood the filtering happens on the temporary variable originated from the return value of the function after it has been called. So the function is executed anyway, with all its eventual side effects, always and never removed.
Is this correct?
This is happening on the intermediate code, after front end parsing and possible simplification of expressions. Intrinsic functions in it's enabled/intrinsic form are handled differently, but otherwise a call is always either call(...) or tmp = call (...). Both call forms/statements are assumed to have side-effects, and can't be removed, unless the call site is unreachable and the code is optimized. A single comparison is another type of intermediate statement: a larger C condition like "a > 0 && b > 0" will result in two comparison statements jumping to different true/false labels. All intermediate statements can have associated source coordinates for warnings and errors.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on July 30, 2021, 09:10:55 PM
Consider the following snippet:
Code: [Select]
bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
{
free(regs);
return false;
}
if (!check(regs))
{
free(regs); //<--  warning #2116: Local 'regs' is used without being initialized (or using a dangling value).
return false;
}
return true;
}
The compiler doesn't consider that after releasing memory no more code will be executed in this function.
In more complicate functions the noise of warnings would be considerable, unless the code is modified, possibly making it less readable, to avoid the warning.
The workaround, to avoid very complicate if-else nesting is:
Code: [Select]
bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
goto error;

if (!check(regs))
goto error;
return true;
error:
free(regs);
return false;
}
It would be nice if the compiler can consider the end of function (the return) also on variables changes.

This uses the SSA form. Apparently you are not optimizing, which would have been good to know, to get this warning. I'm not sure how useful this is anymore. Anyway, not optimizing at all will leave some artifacts in the SSA form (unreferenced SSA variables, PHI-functions). These can probably be removed fairly easy, but if the promise is to not optimize at all this is at least borderline...
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 30, 2021, 09:46:44 PM
This is happening on the intermediate code, after front end parsing and possible simplification of expressions. Intrinsic functions in it's enabled/intrinsic form are handled differently, but otherwise a call is always either call(...) or tmp = call (...). Both call forms/statements are assumed to have side-effects, and can't be removed, unless the call site is unreachable and the code is optimized. A single comparison is another type of intermediate statement: a larger C condition like "a > 0 && b > 0" will result in two comparison statements jumping to different true/false labels. All intermediate statements can have associated source coordinates for warnings and errors.
Thanks for the confirmation, that's what I supposed should be the correct behavior.
This uses the SSA form. Apparently you are not optimizing, which would have been good to know, to get this warning. I'm not sure how useful this is anymore. Anyway, not optimizing at all will leave some artifacts in the SSA form (unreferenced SSA variables, PHI-functions). These can probably be removed fairly easy, but if the promise is to not optimize at all this is at least borderline...
You're right I'm not optimizing, and after optimizations the warning doesn't appear anymore.
What's impressive indeed is the optimization workout. The following snippet don't produce the waning anyway:
Code: [Select]
bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
{
if (n<100)
free(regs);
printf("blah blah blah\n");
return false;
}
if (!check(regs))
{
free(regs);
return false;
}
return true;
}
Notwithstanding the difference in the two if's it could understand that the two free() calls are mutually exclusive.  :o
Really good job indeed  8)
Title: Re: Release Candidate for version 11.00 is now available
Post by: Marco on July 31, 2021, 06:00:16 PM
Hi Pelle. Today I was adding some new functions to my personal library. I changed the parameter type of a function but I forgot to change the same type parameter also in the prototype of that function. Due to this, the compiler showed the following fatal error:
Code: [Select]
fatal error: Internal error: composite_type().

A very simple example to replicate the error:
Code: [Select]
void foo(int, void *);         <-- definition

void foo(int n, int *p)        <-- function
{
  n = 0;
}
There is no need to call the 'foo' function somewhere in the code. The error occurs during the compilation. Just to let you know.
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on July 31, 2021, 06:22:05 PM
Quote
error #2281: Undeclared name 'time'. Did you forget '#include <time.h>'?
Very nice  8)
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on August 01, 2021, 08:11:57 PM
This is happening on the intermediate code, after front end parsing and possible simplification of expressions. Intrinsic functions in it's enabled/intrinsic form are handled differently, but otherwise a call is always either call(...) or tmp = call (...). Both call forms/statements are assumed to have side-effects, and can't be removed, unless the call site is unreachable and the code is optimized. A single comparison is another type of intermediate statement: a larger C condition like "a > 0 && b > 0" will result in two comparison statements jumping to different true/false labels. All intermediate statements can have associated source coordinates for warnings and errors.
Thanks for the confirmation, that's what I supposed should be the correct behavior.
This uses the SSA form. Apparently you are not optimizing, which would have been good to know, to get this warning. I'm not sure how useful this is anymore. Anyway, not optimizing at all will leave some artifacts in the SSA form (unreferenced SSA variables, PHI-functions). These can probably be removed fairly easy, but if the promise is to not optimize at all this is at least borderline...
You're right I'm not optimizing, and after optimizations the warning doesn't appear anymore.
What's impressive indeed is the optimization workout. The following snippet don't produce the waning anyway:
Code: [Select]
bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
{
if (n<100)
free(regs);
printf("blah blah blah\n");
return false;
}
if (!check(regs))
{
free(regs);
return false;
}
return true;
}
Notwithstanding the difference in the two if's it could understand that the two free() calls are mutually exclusive.  :o
Really good job indeed  8)

Looks like a selective "dead code elimination", for non-optimized code, can silence the most obvious warnings (without changing much else). This is now added to the compiler.
Title: Re: Release Candidate for version 11.00 is now available
Post by: Pelle on August 01, 2021, 08:14:06 PM
Hi Pelle. Today I was adding some new functions to my personal library. I changed the parameter type of a function but I forgot to change the same type parameter also in the prototype of that function. Due to this, the compiler showed the following fatal error:
Code: [Select]
fatal error: Internal error: composite_type().

A very simple example to replicate the error:
Code: [Select]
void foo(int, void *);         <-- definition

void foo(int n, int *p)        <-- function
{
  n = 0;
}
There is no need to call the 'foo' function somewhere in the code. The error occurs during the compilation. Just to let you know.

This is wrong, but the error could be better. I will see what I can do...
Title: Re: Release Candidate for version 11.00 is now available
Post by: frankie on August 01, 2021, 09:24:59 PM
This is happening on the intermediate code, after front end parsing and possible simplification of expressions. Intrinsic functions in it's enabled/intrinsic form are handled differently, but otherwise a call is always either call(...) or tmp = call (...). Both call forms/statements are assumed to have side-effects, and can't be removed, unless the call site is unreachable and the code is optimized. A single comparison is another type of intermediate statement: a larger C condition like "a > 0 && b > 0" will result in two comparison statements jumping to different true/false labels. All intermediate statements can have associated source coordinates for warnings and errors.
Thanks for the confirmation, that's what I supposed should be the correct behavior.
This uses the SSA form. Apparently you are not optimizing, which would have been good to know, to get this warning. I'm not sure how useful this is anymore. Anyway, not optimizing at all will leave some artifacts in the SSA form (unreferenced SSA variables, PHI-functions). These can probably be removed fairly easy, but if the promise is to not optimize at all this is at least borderline...
You're right I'm not optimizing, and after optimizations the warning doesn't appear anymore.
What's impressive indeed is the optimization workout. The following snippet don't produce the waning anyway:
Code: [Select]
bool build_regs(int n)
{
REGS *regs = calloc(sizeof(REGS), n);
if (!regs)
return false;
if(!init_regs(regs))
{
if (n<100)
free(regs);
printf("blah blah blah\n");
return false;
}
if (!check(regs))
{
free(regs);
return false;
}
return true;
}
Notwithstanding the difference in the two if's it could understand that the two free() calls are mutually exclusive.  :o
Really good job indeed  8)

Looks like a selective "dead code elimination", for non-optimized code, can silence the most obvious warnings (without changing much else). This is now added to the compiler.
Very good. thanks.