Release Candidate for version 11.00 is now available

[Pelle]

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...

[Pelle]

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...

[Pelle]

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

Very good - thanks!

[frankie]

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... 
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. 

[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 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...

[Pelle]

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).

[frankie]

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...

[Pelle]

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...?

[Marco]

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

[frankie]

- 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.

[Pelle]

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...

[Marco]

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.
{
}


[frankie]

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.

[Marco]

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.


[John Z]

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