Release Candidate for version 11.00 is now available

[algernon_77]

Happy to report that all seems to be ok now 
Thanks!

[Marco]

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

[Marco]

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.

[John Z]

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

[Pelle]

Happy to report that all seems to be ok now 
Thanks!

Very good - thanks!

[Pelle]

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

[Marco]

<snip>
Mystery solved though 

Yep! 

[Marco]

<snip>
I have to think about this...

Thanks for your explanation, Pelle.

Marco

[frankie]

Good job Pelle! 

[Grincheux]

Vacation now Mr Pelle.

[Marco]

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.

[Pelle]

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?

[Marco]

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

[frankie]

It seems that replace won't work if the 'with' field is empty.
Practically is impossible to use the replace to remove something.

[Vortex]

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.