Author: Dann Corbit
Date: 16:08:21 06/11/04
Go up one level in this thread
On June 11, 2004 at 15:36:29, Uri Blass wrote:
>On June 11, 2004 at 14:03:14, Dann Corbit wrote:
>
>>On June 11, 2004 at 13:28:54, Uri Blass wrote:
>>
>>>On June 11, 2004 at 13:03:43, Dann Corbit wrote:
>>>
>>>>On June 11, 2004 at 09:42:25, Uri Blass wrote:
>>>>
>>>>>On June 11, 2004 at 09:04:28, Rémi Coulom wrote:
>>>>>
>>>>>>On June 11, 2004 at 08:30:29, Uri Blass wrote:
>>>>>>
>>>>>>>I have a version of movei that is movei00_8_236.exe
>>>>>>>
>>>>>>>It is using a lot of files when the number 236 is in it.
>>>>>>>
>>>>>>>When I change to movei00_8_237.exe I want the new version to use files with the
>>>>>>>number 237 in it(the reason is that otherwise if I put both 236.exe and 237.exe
>>>>>>>in the same folder they use the same files and can change the same book files
>>>>>>>and I do not want 237 to learn to change it's book from games of 236).
>>>>>>>
>>>>>>>Of course it is possible to put 236 and 237 in different folders but I do not
>>>>>>>like this solution.
>>>>>>>
>>>>>>>I think that the best solution is to tell the program to read the name of the
>>>>>>>exe file and copy it to a string and use it when it decide about the names of
>>>>>>>the files that it reads or create.
>>>>>>>
>>>>>>>
>>>>>>>The question is how to do it.
>>>>>>>
>>>>>>>Uri
>>>>>>
>>>>>>if your main function is
>>>>>>
>>>>>>int main(int argc, char *argv[])
>>>>>>
>>>>>>then argv[0] is the name of the exe
>>>>>>
>>>>>>Rémi
>>>>>
>>>>>Thanks
>>>>>
>>>>>It is
>>>>>__cdecl main(void)
>>>>>
>>>>>I do not remember why I need the cdecl and it was a long time ago but if I
>>>>>remember correctly I needed it when I tried to change the .c files to .cpp
>>>>>files(I do not use C++ code but only C but I find it easier to do things with
>>>>>cpp code(for example I know from experience that checking bounds does not work
>>>>>correctly with files that end with .c).
>>>>
>>>>Some compilers do some rudimentary bounds checking. However, the reliable way
>>>>to do it is to use a bounds checker. There are lots of them.
>>>
>>>I have bound checkers
>>>
>>>I found that it did not work correctly with C files and the reply that I got
>>>from compuware that it is a limitation of the C language.
>>>
>>>Here is a simple program that I generated to demonstrate the problem:
>>>
>>>
>>>#include "stdio.h"
>>>
>>>
>>>
>>>typedef struct
>>>{
>>> int m;
>>> int n;
>>>
>>>}
>>>hist_t;
>>>
>>>hist_t PADDED_hist_dat[1000];
>>>hist_t * const hist_dat=PADDED_hist_dat+1;
>>>
>>>void main(void)
>>>{
>>> int sq;
>>> for (sq=998;sq<=1000;sq++)
>>> printf(" %d ", hist_dat[sq].n);
>>>}
>>>
>>>
>>>boundchecker finds a mistake only when sq=1000
>>
>>It is understandably difficult to track a pointer when due to alignment or the
>>presence of other data, the element addressed may actually live in your data
>>space.
>>
>>>Note that if I replace
>>> printf(" %d ", hist_dat[sq].n);
>>>by
>>> printf(" %d ", hist_dat[sq].m);
>>>
>>>boundcheker reports an error in the right time when sq=999
>>
>>This is not a function of C or C++ language. There is no logical reason why
>>they can find the error with C++ but not with C.
>>
>>>The reply that I got from compuware was that it is not a bug in checkerbound but
>>>limitation of the C language:
>>>
>>>" IF this code is compiled as a .cpp, we know from the
>>>symbol table that the struct hist_t is actually an 8 byte object, but under
>>>C, the symbol table only contains the size of the member, so we fail to
>>>report the overrun at the correct point for the member variable m since we
>>>are only looking ahead 4 bytes rather than the full 8."
>>
>>They should be able to instrument the code to detect the error.
>>
>>In this tiny program, there are other errors, some of which you may not expect.
>>
>>Are you aware that the main() function should *not* be declared as returning
>>void?
>
>dependent on your definition of error.
>
>If the application runs there are no errors that the computer see(otherwise the
>program cannot run)
>
>If you want to convince me that it is an error then you need to explain what
>problems can be because of that definition.
It can crash the computer, do nothing out of the ordinary, or cause Scott Nudds
to come flying out of your nose. Using "void main()" is an example of undefined
behavior.
If you think I am being mellodramatic, I once sent a program to calculate pi to
a fellow in England. It crashed his computer system. We traced the problem to
"void main(void)".
For some compilers, void main() is allowed as an undocomented extension.
However, the next iteration of the compiler may cause it to crash, to format
your hard disk, or to cause your computer to hop about the room while whistling
the star spangled banner.
From the C FAQ:
1.25b: What's the right declaration for main()?
Is void main() correct?
A: See questions 11.12a to 11.15. (But no, it's not correct.)
11.12a: What's the correct declaration of main()?
A: Either int main(), int main(void), or int main(int argc,
char *argv[]) (with alternate spellings of argc and *argv[]
obviously allowed). See also questions 11.12b to 11.15 below.
References: ISO Sec. 5.1.2.2.1, Sec. G.5.1; H&S Sec. 20.1 p.
416; CT&P Sec. 3.10 pp. 50-51.
11.12b: Can I declare main() as void, to shut off these annoying
"main returns no value" messages?
A: No. main() must be declared as returning an int, and as
taking either zero or two arguments, of the appropriate types.
If you're calling exit() but still getting warnings, you may
have to insert a redundant return statement (or use some kind
of "not reached" directive, if available).
Declaring a function as void does not merely shut off or
rearrange warnings: it may also result in a different function
call/return sequence, incompatible with what the caller (in
main's case, the C run-time startup code) expects.
(Note that this discussion of main() pertains only to "hosted"
implementations; none of it applies to "freestanding"
implementations, which may not even have main(). However,
freestanding implementations are comparatively rare, and if
you're using one, you probably know it. If you've never heard
of the distinction, you're probably using a hosted
implementation, and the above rules apply.)
References: ISO Sec. 5.1.2.2.1, Sec. G.5.1; H&S Sec. 20.1 p.
416; CT&P Sec. 3.10 pp. 50-51.
11.13: But what about main's third argument, envp?
A: It's a non-standard (though common) extension. If you really
need to access the environment in ways beyond what the standard
getenv() function provides, though, the global variable environ
is probably a better avenue (though it's equally non-standard).
References: ISO Sec. G.5.1; H&S Sec. 20.1 pp. 416-7.
11.14: I believe that declaring void main() can't fail, since I'm
calling exit() instead of returning, and anyway my operating
system ignores a program's exit/return status.
A: It doesn't matter whether main() returns or not, or whether
anyone looks at the status; the problem is that when main() is
misdeclared, its caller (the runtime startup code) may not even
be able to *call* it correctly (due to the potential clash of
calling conventions; see question 11.12b).
It has been reported that programs using void main() and
compiled using BC++ 4.5 can crash. Some compilers (including
DEC C V4.1 and gcc with certain warnings enabled) will complain
about void main().
Your operating system may ignore the exit status, and
void main() may work for you, but it is not portable and not
correct.
11.15: The book I've been using, _C Programing for the Compleat Idiot_,
always uses void main().
A: Perhaps its author counts himself among the target audience.
Many books unaccountably use void main() in examples, and assert
that it's correct. They're wrong.
>>Do you know the difference between angle brackets and double quotes for header
>>files? System headers should definitely be included with angle brackets.
>
>I do not see why it is important if the program works in both cases.
>I understand that I should use "" for files that I generated and <> for files
>that the library generated but I do not see why it is important.
Your car might run for a while if you keep putting water in the oil hole and oil
in the water hole.
>In movei I have in main.cpp #include <> for library files but in other files I
>have in part of the cases #include "" also for library files and as far as I
>know for some reason it caused no problem in running the program.
Again, from the C FAQ:
10.8a: What's the difference between #include <> and #include "" ?
A: The <> syntax is typically used with Standard or system-supplied
headers, while "" is typically used for a program's own header
files.
10.8b: What are the complete rules for header file searching?
A: The exact behavior is implementation-defined (which means that
it is supposed to be documented; see question 11.33).
Typically, headers named with <> syntax are searched for in one
or more standard places. Header files named with "" syntax are
first searched for in the "current directory," then (if not
found) in the same standard places.
Traditionally (especially under Unix compilers), the current
directory is taken to be the directory containing the file
containing the #include directive. Under other compilers,
however, the current directory (if any) is the directory in
which the compiler was initially invoked. Check your compiler
documentation.
References: K&R2 Sec. A12.4 p. 231; ISO Sec. 6.8.2; H&S Sec. 3.4
p. 55.
Here is a link to the C FAQ:
ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/lang/c/C-FAQ-list
Well worth reading. If you read and understand it you will not only make
yourself a better C programmer, but you will save yourself a lot of trouble.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.