jwes wrote:
btw, if you could separate substantive changes from more cosmetic changes, it would make diff more useful, e.g. release a version with the new print specifier, functions with changed parameter order, and reformatted comments, and a second version with new SMP, pawn eval, and pruning.
There are some strange fixes. For example, memset().
Here is the man page for memset:
SYNOPSIS
#include <string.h>
void *
memset(void *b, int c, size_t len);
First argument is supposed to be a void pointer, not a char pointer. A char pointer produces a warning on my boxes.
MSVC complains that it can't do pointer addition on a void pointer since it does not know what size it is. Perhaps you need to use
getpid is another strange one. That is a library call and the compiler should add the _ to it automagically as it has been doing for MANY years. Is this a brand new version of MSVC???
Ditto for fileno and isatty() functions. Here is how fileno() is supposed to be called:
int
fileno(FILE *stream);
Adding an _ breaks the world. And for me, the compiler adds the _ to match up with the library name automatically. ALL C functions pretty much start with _. printf(), scanf(), etc... Yet we don't add "_" to them ourselves, that's the compiler's task.
MSVC gives the error message "This POSIX function is deprecated. Use the ISO C++ conformant _getpid instead." and the same for fileno and isatty.
The boolean.c fix for popcnt() had already been found and fixed so that 25.0 could be used by CCRL.
Can't explain what your MSVC compiler is doing, or why. But something is badly wrong somewhere since it has been compiling cleanly elsewhere. Peter Skinner compiles for windows for testing and it has been compiling just fine for him as well...
jwes wrote:
btw, if you could separate substantive changes from more cosmetic changes, it would make diff more useful, e.g. release a version with the new print specifier, functions with changed parameter order, and reformatted comments, and a second version with new SMP, pawn eval, and pruning.
There are some strange fixes. For example, memset().
Here is the man page for memset:
SYNOPSIS
#include <string.h>
void *
memset(void *b, int c, size_t len);
First argument is supposed to be a void pointer, not a char pointer. A char pointer produces a warning on my boxes.
MSVC complains that it can't do pointer addition on a void pointer since it does not know what size it is. Perhaps you need to use
getpid is another strange one. That is a library call and the compiler should add the _ to it automagically as it has been doing for MANY years. Is this a brand new version of MSVC???
Ditto for fileno and isatty() functions. Here is how fileno() is supposed to be called:
int
fileno(FILE *stream);
Adding an _ breaks the world. And for me, the compiler adds the _ to match up with the library name automatically. ALL C functions pretty much start with _. printf(), scanf(), etc... Yet we don't add "_" to them ourselves, that's the compiler's task.
MSVC gives the error message "This POSIX function is deprecated. Use the ISO C++ conformant _getpid instead." and the same for fileno and isatty.
The boolean.c fix for popcnt() had already been found and fixed so that 25.0 could be used by CCRL.
Can't explain what your MSVC compiler is doing, or why. But something is badly wrong somewhere since it has been compiling cleanly elsewhere. Peter Skinner compiles for windows for testing and it has been compiling just fine for him as well...
The char * to void * idea is what I had decided to use. Makes it a bit harder to read, however.
I looked thru my gcc/icc stuff and I don't see any reference to getpid() being deprecated. Is this a microsoft thing?
bob wrote:
I looked thru my gcc/icc stuff and I don't see any reference to getpid() being deprecated. Is this a microsoft thing?
Yes, it is. In fact they marked a good chunk of the standard library as deprecated a few years ago.
So Microsoft only? Wonderful.
Microsoft deprecated a lot of functions (especially string functions) because they are potentially unsafe and replaced them by safe versions.
This doesn't mean you can't use them anymore, if you want to get rid of all the warnings you just have to define _CRT_SECURE_NO_WARNINGS
You can also disable the warnings by #pragma warning(disable:4996)
bob wrote:
I looked thru my gcc/icc stuff and I don't see any reference to getpid() being deprecated. Is this a microsoft thing?
Yes, it is. In fact they marked a good chunk of the standard library as deprecated a few years ago.
So Microsoft only? Wonderful.
Microsoft deprecated a lot of functions (especially string functions) because they are potentially unsafe and replaced them by safe versions.
This doesn't mean you can't use them anymore, if you want to get rid of all the warnings you just have to define _CRT_SECURE_NO_WARNINGS
You can also disable the warnings by #pragma warning(disable:4996)
However, how would "getpid()" be unsafe? Not even a string function.
bob wrote:The char * to void * idea is what I had decided to use. Makes it a bit harder to read, however.
Check if you really need to spell out the explicit (void*) cast to suppress warnings. Normally you can leave that cast implicit if the prototype is known (and when compiling in C mode at least) and keep things a bit more readable.
You will need an explicit (char*) for arithmetic and be portable.
bob wrote:The char * to void * idea is what I had decided to use. Makes it a bit harder to read, however.
Check if you really need to spell out the explicit (void*) cast to suppress warnings. Normally you can leave that cast implicit if the prototype is known (and when compiling in C mode at least) and keep things a bit more readable.
You will need an explicit (char*) for arithmetic and be portable.
Some versions have been complaining, which is why I changed it to start with. Not sure what the gcc guys are doing nowadays...
bob wrote:The char * to void * idea is what I had decided to use. Makes it a bit harder to read, however.
Check if you really need to spell out the explicit (void*) cast to suppress warnings. Normally you can leave that cast implicit if the prototype is known (and when compiling in C mode at least) and keep things a bit more readable.
You will need an explicit (char*) for arithmetic and be portable.
Some versions have been complaining, which is why I changed it to start with. Not sure what the gcc guys are doing nowadays...
There are two issues intermingled in this thread:
1. implicit cast to void* (should be fine) and 2. arithmetic on void* as if it were a char* (can be rightfully flagged as an error, as it is a language extension originating from gnu but spread out to more platforms but not all).
Can you be clear about which compiler complains about the first case: implicit cast to void*? I'm not talking about the arithmetic on void*, but about the passing of a non-void* to a properly prototyped function that accepts void* but is given another pointer type. I do the implicit casting in Floyd and other programs and have not heard about compilers complaining (yet) if they are instructed to compile C, and people use a wide variety of them.
From readability point of view it would be a pity if you need two consecutive casts. The need for char* for arithmetic is understandable from the language definition. Sometimes people just blindly add casts until the warnings go away, while it might be better to look at what is happening, maybe rearrange some parenthesis and achieve the same.
bob wrote:The char * to void * idea is what I had decided to use. Makes it a bit harder to read, however.
Check if you really need to spell out the explicit (void*) cast to suppress warnings. Normally you can leave that cast implicit if the prototype is known (and when compiling in C mode at least) and keep things a bit more readable.
You will need an explicit (char*) for arithmetic and be portable.
Some versions have been complaining, which is why I changed it to start with. Not sure what the gcc guys are doing nowadays...
There are two issues intermingled in this thread:
1. implicit cast to void* (should be fine) and 2. arithmetic on void* as if it were a char* (can be rightfully flagged as an error, as it is a language extension originating from gnu but spread out to more platforms but not all).
Can you be clear about which compiler complains about the first case: implicit cast to void*? I'm not talking about the arithmetic on void*, but about the passing of a non-void* to a properly prototyped function that accepts void* but is given another pointer type. I do the implicit casting in Floyd and other programs and have not heard about compilers complaining (yet) if they are instructed to compile C, and people use a wide variety of them.
From readability point of view it would be a pity if you need two consecutive casts. The need for char* for arithmetic is understandable from the language definition. Sometimes people just blindly add casts until the warnings go away, while it might be better to look at what is happening, maybe rearrange some parenthesis and achieve the same.
I will have to go back and test. But either gcc 4.6, 4.7, 4.8 or 5.0 complained. Only a warning. A similar problem with pthread_create().
