C coding guidelines

[Bart]

Richard Heathfield a écrit :

Look. One way to cinvince yourself that dllmain is called
before your program starts is to use the debugger

(1) Write a DllMain function

Here is the code that you can cut/paste to do that:

int WINAPI LibMain(HINSTANCE hDLLInst, DWORD Reason, LPVOID Reserved)
{

Note that I did not call the entry point DllMain but LibMain,
just to prove you that the name is USER DEFINED.- Hide quoted text -

Why are you using LibMain after discussing DllMain for several posts?

I can get the entry point of a Dll to work if it's called LibMain, but
not if it's called DllMain, using lccwin32; why not?

And what is the meaning that the name is user-defined? Both DllMain
and LibMain appear to be specially recognised names, not requiring
link switches to identify.

 

[Alan Curry]

So we obviously disagree over the meaning of the term "entry point".
I'm using it to describe the point (or points) at which control flow
enters user code.

And everyone else knows that it's the standard name for a particular field in
the header of the file format under discussion. You could probably google
"DLL entry point", and find a hundred independent descriptions of the file
format that all use the same terminology. An even better keyword to search
for would be "AddressOfEntryPoint" which is the usual name for the field when
the EXE file headers are laid out as C structs.

In one of the many available references, I read that DLLs aren't required to
have an entry point, and the AddressOfEntryPoint field may be 0 to indicate
that there isn't one. But your demo has quite a big one, 86 instructions
long, and there are a few other functions which are called from it. Clearly a
default entry function was provided for you somehow. Way to completely miss
demonstrating the point you thought you had.

 

[Alan Curry]

Actually, the C Standard doesn't define "entry point". In the context
of this newsgroup, therefore, there is no standard definition, so we

This thread hasn't been about C for quite a while. Your insistence on trying
to extract "standard C" meaning from phrases that are defined outside of C
only makes you look ignorant.

"Entry point" is not a C term. It is a common term in describing executable
file formats. As soon as it came into play, the thread had drifted into an
area where your "standard C is the universe" approach was no longer adequate.

When the thread drifted away from things you are knowledgeable about, you
could have chosen to stop participating, or you could have chosen to educate
yourself enough to participate productively. You chose the third option: plow
ahead without knowing what you're talking about.

 

[jacob navia]

Alan Curry a écrit :

This thread hasn't been about C for quite a while. Your insistence on trying
to extract "standard C" meaning from phrases that are defined outside of C
only makes you look ignorant.

"Entry point" is not a C term. It is a common term in describing executable
file formats. As soon as it came into play, the thread had drifted into an
area where your "standard C is the universe" approach was no longer adequate.

When the thread drifted away from things you are knowledgeable about, you
could have chosen to stop participating, or you could have chosen to educate
yourself enough to participate productively. You chose the third option: plow
ahead without knowing what you're talking about.

It is impossible. I tried and tried, and he will just

[snip]

all the code I sent him to try for himself in his environment and
see for himself that the entry point is called by the system loader.

Notwithstanding the whole documentation from Microsoft, the
documentation of his compiler he used to compile the dll.

At the end I told him he is right, he was happy and its over

 

[jacob navia]

Richard Heathfield a écrit :

It is impossible. I tried and tried, and he will just

[snip]

all the code I sent him to try for himself in his environment and
see for himself that the entry point is called by the system loader.

The problem with the code you supplied was that it was irrelevant to
the question being discussed, which was basically a matter of
terminology.

<snip>

You see?

It is impossible!



The code I sent you proved to you that the entry point
is called before main() starts. That means that dlls
have an entry point, written in the executable file header.

The name of the entry point is user defined. Since you
don't supply one, the compiler provides a default one.

But now you will answer that an entry point is not an entry
point in the sense you wanted or whatever.

Ok. You are right (again)

Happy?

 

[Seebs]

But now you will answer that an entry point is not an entry
point in the sense you wanted or whatever.

His point, I think, is that the thing you describe is not a necessary
part of all possible C implementations, and there is nothing in the
language specification called an "entry point". (I think there was talk
of one, at one point, using the keyword entry, but it never materialized.)

In short, it may well be that there is a thing in your implementation, and
probably in many others, which implementors or operating system people call
"an entry point". However, the term has no general meaning in the context
of C programming. If someone else came along with a new system, and used
the term "entry point" to mean something entirely different, they would not
be wrong from the point of view of C development.

-s

 

[Tech07]

Richard Heathfield a écrit :


Fine. Then, as you (may) know, all dlls have
a point where control enters user code for the first time.

Got it?

This is the dllmain function!


Correct.

That's not correct. It may be subjective to what "user" you are. The
well-accepted entry point to Windows executables is WinMainCRTStartup.

 

[Tech07]

Richard Heathfield a écrit :

This is what you refuse to understand Mr Heathfield.

ALL dlls will be called BY THE LOADER before the program starts.

This is NOT a call y your user code, it is a call by the
operating system and you can't do anything to avoid it.

This call will be done to a special entry point called DllMain
in the literature but can be actually any function that is
defined as entry point by the user.

The loader finds the address to call by looking at the header
of the dll. For instance, in the dll you sent me, the header
has the entry point field with a value of 0x1220 (4640 decimal)

This means that the loader will call the address:

DLL load point + 4640.

This is the address of the DllMain procedure. Note that this
address will change, depending on the address the dll itself
is loaded.

This call has standard arguments, described in the documentation.
It will receive those argumùents that allow it to see WHY it was
called.
There are 4 calls to the entry point of the dll:
1) Before starting the program. Here the dll can use this occasion
to initilize stuff
2) When a new thread is started. Here the dll can initilize things in
a per thread basis
3) When a thread ends. Here you can do the opposite of what you
did at (2).
4) Just before when the program ends. Here you do the opposite as (1).



This is correct, but has nothing to do with the calls
done not by your code but by the code of the operating
system (the system program loader)


You are right that here the entry point is foo(). But, that has
nothing to dow with the entry point OF THE DLL.


The call to the entry point is transparent to you. Since you did NOT
define an entry point, the compiler supplied you automatically
an entry point function that returns always TRUE and does nothing.

Then, you do not see it.

You can convince yourself of that by making a DllMain function
that always returns ZERO. You will see that the system will
refuse to load your dll!


I use pedump.exe to dump dlls. Your dll has an entry point of
0x1220



Look. One way to cinvince yourself that dllmain is called
before your program starts is to use the debugger

"Call me stupid", but I just read the documentation umpteen years ago. I
even provided a link to it.

 

[Tech07]

We are talking about the entry point into user code.


Then it's not the entry point into the DLL.


The DLL I have shown in this thread has two entry points - foo and
bar. It seems you are now conceding this.



Then we have a terminology disagreement, and it should not be
necessary to point out that such disagreements are hardly ever
resolved to anyone's satisfaction.

You mean you just can't handle being wrong. (Of course that's not it, you
feel "dumb" for not knowing Windows' internals and what the REAL entry point
is. Don't fret: it's no big deal. I'm just a practicianer myself, not a
scientist or "language lawyer" (not that they aren't necessary or "bad"!)).

 

[Tech07]

The entry point is the point at which control flow enters user code.

For a Windows executable, that point is WinMainCRTStartup. Deal with it.
Fine, you're a "user" beyond the main() level and "you don't need to know"
anything else (ignorance is bliss), but you shouldn't curb other people's
potential knowledge to your own with such curbing bullshit for any reason
(take your pride outside). If you were trolling, I will put you on ignore
(the next time I catch you doing it).

Good example of <something>, this tangential thread was.

 

[Tech07]

Alas, I *have* to handle being wrong far more often than I'd like.
Nevertheless, I don't think this is one such occasion. I think it's
just a terminology dispute.


Well, you obviously think you know my thought processes better than I
do, but I was thinking purely in C terms, this being a C newsgroup
and all.


It seems you also think you're a mind-reader.

"psychic" (I figured there was no money in it so I went to college. Boy was
I wrong!).

 

[Tech07]

WinMainCRTStartup is not user code, from the perspective of a C
program. Deal with it.

Oh, so now it's not "user" at all. It's "a C program perspective". First, is
English your first or only language? (I wanna give a lot of slack to those
for which their primary language is not English, because I'm like a
Corvette: I hold the road up to the ragged edge, but when that boundary is
crossed, all bets are off (Trans Ams were WAY more fun to drive, especially
in the rain!)). Where in the C standard do they discuss "entry point"?

Good example of the problems that can arise when people don't agree on
terminology at the outset.

Historically, that will be written against your claim. ("I just know" ).

 

[Bart]

Richard Heathfield wrote:

For a Windows executable, that point is WinMainCRTStartup. Deal with it.
Fine, you're a "user" beyond the main() level and "you don't need to know"
anything else (ignorance is bliss), but you shouldn't curb other people's
potential knowledge to your own with such curbing bullshit for any reason
(take your pride outside). If you were trolling, I will put you on ignore
(the next time I catch you doing it).

Ok, we acknowledge you're a superior being because you've managed to
program something outside the cosy confines of a C language
environment. And?

 

[spinoza1111]

arnuld said:


You have left out far too much.

No, he put in far too much. His C coding guidelines should be three
words:

DON'T USE C

 

[spinoza1111]

I have written C coding guidelines for my company. All of those
guidelines  I have learned from this newsgroup. So I thought it will a be
good idea if you people can have a look and advise on improvement or
anything else:

==== The Compilation Phase ====

The default compiler that comes with Linux is gcc and System Programming
team of Phonologies uses the same. In Phonologies, we work as a part of a
team. A project is divided into difference pieces/sections and each piece
is given to each team member to code. You have to work as an independent
programmer to code that piece. All pieces are joined together to form a
complete software and they joined and then re-edited and tested many
times before finally labeled as "ready to release". To do that work
properly, we have some guidelines that reduce the overall bugs,
production time and of course the tension generated by future problems.
Whenever you pass a piece of code to your fellow team-mate, you pass it
after compiling and running it successfully on your machine.  You will
use either "gcc -ansi -pedantic -Wall -Wextra" or "gcc -std=c99 -pedantic
-Wall -Wextra" to compile your programs. If you are interested in knowing
what *exactly* all of those flags do, please refer to the gcc manual. At
no point of time you will ever pass the program to anyone in the team
without using these flags. These flags will tell you about lots of bugs
and run-time problems before they even surface. It is your responsibility
to remove the bugs and clear the program of all the run-time anomalies of
your own programs, not of your team's. There are no Sir(s) in
Phonologies, there are no attitudes like "yes boss", or "Sir, you are
genius". At Phonologies we are a family, one family member will not bear
the consequences of the problems created by other member just because
that *other* member is unwilling to do hard-work. (We don't work like the
obsolete USSR). Your code, Your responsibility.

==== Team Spirit ====
When the pieces of software are combined and being tested and then if
some bugs come up  and they will surely come up, then it will not be like
""Arnuld wrote this code and therefore I will not solve this bug"". We
are team, so please behave like a team. The reply ""Sumit wrote this
code, so he knows better about it and he can fix it sooner than me"" is
very different from the former. Now if somehow, Sumit is working on
fixing some other important issues  and handling some other tasks which
have priority then you will fix this bug. Yes..., you can go and talk to
him (when he will have free time) about his design, code and the way he
programmed this piece but since he does not have time, it is you who will
fix the current bug. One of our ex-employees *Saurabh Nirkhey* worked
hard on flourishing this team-spirit.

==== Practices that are Frowned Upon  ====

" void main() ":  "main()" will always return int. You will never use
"void main()". If you are still using "void main()" and wonder about this
guideline then trust me you are still living in academic world. Wake up

Excuse me, please don't use the phrase "academic world" to mean
"things we don't like". The academic world makes your hardware and
software possible, in large measure. It provides you with quality
employees.

If you mean by the "academic world" the sort of back-talk and
discussion that some professors encourage at some universities, please
be aware that the most successful software companies in the world
encourage back-talk and discussion, as opposed to back-stabbing and
personality destruction.

and deal with the reality, use "int main(void)" or "int main(int argc,
char* argv[])". Every C program returns a value to the shell that helps
in knowing the reasons of success or failure or sudden crash or even
semantic errors. When you write "void main()"  you *specifically* tell
the shell that you are more intelligent than "Donald Knuth" and do not

Some of your people may be. Don't prejudge them, please. If you've
happened to have hired "the next" Knuth, do you really want him to
leave you when he gets another job offer, because you've said that
he's not intelligent, in so many words?

need to know the cause of the problem, that you are exceptionally
intelligent and you don't need any help from the compiler to solve the
problem. I am sorry, we do, not everyone is as intelligent as you, we

I accept your justification for using int main: but the most
intelligent programmers check their errors. It's really offensive to
tell your employees that they are stupid.

Bjarne Stroustrup, the creator of C++ has in fact an excellent
argument not only for checking errors but for leaving error checking
in: a part-time sailor, he asks if a sailor would discard his
lifeboats after "testing" in the harbor and venturing out into the
sea. He's very intelligent!

need to identify and fix the problems without wasting any time or
efforts. Hence we need "int main(void)" or "int main(int argc, char*
argv)". You may wonder that we use "int main(void)" rather than "int main
()". Its because, in C, an empty parenthesis means you can pass unlimited
number of arguments to the function. To tell the C compiler that you are
not expecting an argument you write void in those parenthesis. (In C++ an
empty parenthesis means no arguments are being passed, C and C++ are not
same languages, remember this)

"Not Function Parameters":  Always check function parameters for NULL

Even ints? I'm not criticising you. I don't know why you would want to
do this for parameters that are not pointers.

values. You must check for unexpected values before you start to use
them. Any code that does not do so will not pass Phonologies Coding
Standards and hence will be returned back to you in no time and with no
mercy. Be a good neighbor.    

"Sir, Arrays and Pointers are same": Dream on.

=== gcc Warnings ===

Here we will discuss about gcc compile-time warnings. Here is the real-
life run of "app_voiceXML.c" that we use with [[http:"www.asterisk.org/|
Asterisk]].

my-Test.c: In function wait_for_answer:        
my-Test.c:962: warning: implicit declaration of function
senddialevent    
my-Test.c:966: warning: implicit declaration of function get_cid_name    
my-Test.c:966: warning: passing argument 3 of ast_set_callerid makes
pointer from integer without a cast
my-Test.c:1133: warning: implicit declaration of function
onedigit_goto    
my-Test.c: In function VoiceXML_exec:  
my-Test.c:1261: warning: assignment discards qualifiers from pointer
target type    
my-Test.c:1272: warning: assignment discards qualifiers from pointer
target type    
my-Test.c:1284: warning: assignment discards qualifiers from pointer
target type      
my-Test.c:1295: warning: assignment discards qualifiers from pointer
target type      
my-Test.c:1306: warning: assignment discards qualifiers from pointer
target type      
my-Test.c:1320: warning: assignment discards qualifiers from pointer
target type      
my-Test.c:1354: warning: unused variable end      
my-Test.c:1354: warning: unused variable content      
my-Test.c:1534: warning: unused variable dummy      
my-Test.c:1653: warning: too many arguments for format      
my-Test.c:1847: warning: passing argument 3 of ast_call makes integer
from pointer without a cast      
my-Test.c:1879: warning: implicit declaration of function
send_ipx_transfer_result      
my-Test.c:1932: warning: implicit declaration of function sprint      
my-Test.c:1852: warning: unused variable peerflag      
my-Test.c:1774: warning: unused variable who      
my-Test.c:1773: warning: unused variable f      
my-Test.c:1252: warning: unused variable cat      
my-Test.c: At top level:      
my-Test.c:2101: warning: return type defaults to int      
my-Test.c:2101: warning: no previous prototype for
send_ipx_transfer_result      
my-Test.c: In function recv_ack_initial_sdp:      
my-Test.c:736: warning: control reaches end of non-void function      
my-Test.c: In function send_ipx_transfer_result:      
my-Test.c:2117: warning: control reaches end of non-void function      
my-Test.c: At top level:      
my-Test.c:419: warning: print_proto_packet defined but not used      
my-Test.c:517: warning: recv_ack_prepare defined but not used      
my-Test.c:764: warning: send_ipx_prepare defined but not used  

You will never ever discard the gcc warning. Warnings like:

* "passing argument 3 of ast_call makes integer from pointer without a
cast" almost always results in run-time [[http:"en.wikipedia.org/wiki/
Logic_error | semantic error]] that can take days and even months to
solve.

* "control reaches end of non-void function " will result in problems
like return value of a function was going to be passed to some other
function or to be assigned to some variable but function did not return
anything which will again cause run-time semantic error.  

* "send_ipx_prepare defined but not used" . You can ignore it but you
will not. The point is, if there are too many unused variables then some
important warning, for which very few words appear on the screen, can be
lost between the mess of these unused variables. So you have to remove
all the unused variables before you pass this file to the teammate. BTW,
if you are not using a variable whats the point of defining it ?  ..
Don't give me the crap that it can be used in future. In future if it

Remind me never to work for you: I could help you with your English
since later in my thirty year programming career I managed a
translation team in Shenzen ensuring quality Chinese to English
technical translation, but I will not assist you at any price.

I've left jobs where the boss swore at me. I use bad language, but it
should NEVER be used by a person in authority over another. Between
friends, it's usually friendly, and when used to speak truth to power,
it can be very justified. But to write "don't give me the crap" in a
standards manual is UNPROFESSIONAL, sir.

some change/edit is going to be made then we *have to* open and read the
file anyway. We can add your unused variable at that time. Things change
a lot in future, not to mention your own expansion as a programmer which
can force you to rewrite some of your programs.

==== Memory Problems ====

" malloc(), calloc()": In C we use "calloc()" or "malloc()" to allocate
memory. Please avoid them most of the time as using "malloc()" is a CPU
intensive task. When you want to work efficiently, you use static memory.
Hence we advocate the use of Static arrays rather than "malloc()". Of

For business programming where employees can be trained in the built-
in size limits of your software, this is acceptable. For modern OS or
compiler programming, you're asking for some very unhappy customers
when they hit the size limits of static data structures.

course, when you need "caloc()" or "malloc()", you definitely have to use
it. Whenever you use memory allocation you will always check the return
value against NULL. Many Segmentation Faults can be avoided by using this
principle. When a Segmentation Fault comes, it does not tell you from
where it came. Out of all those 16 source files and in those 6000 lines
of code, you have no idea which one produced the Segmentation Fault.
Checking for a NULL can avoid those bitter times that every programmer
does not want to have in his life. A Segfault is PITN (Pain In The Neck),
it kills time, resources, spreads confusion, is the devotee of a Satan,

I enjoy your sense of humor here and your tendency to wax prolix, for
I share it.

is the Diabetes of C program, is the Angel of Death.
Shabash!!

Please check your
return value if you want to keep your program alive and well. A simple
NULL check takes around 60 seconds to type but it can save  days and even
months of debugging. If you count the number of seconds a team of C
Programmers has taken to solve Segfaults, they add up to years of
lifetime and its not an exaggeration.

"Memory Leaks": First make sure you have called "free()" for every "malloc
()" (unless there is some special reason on not to). Then even if your
program is eating up memory, use "valgrind": *valgrind* "--leack-
check=full

read more »...

I don't think I shall. Best of luck to you sir.

 

[spinoza1111]

You say you have a good team spirit in the company .
But try and reread the text,.
I at least find many seemingly condescending err. "expressions"

Maybe its your humor, but be aware that it could create resistance
when "talking down" to your colleagues. or if it is
felt that you do it, even though you don't mean it that way.

like.
"will not be tolerated"
or
"Don't give me the crap that it can be used in future. In future if it
some change/edit is going to be made then we *have to* open and read
the
file"

and a lot more.

from your writing, i would think that you have a lacking team spirit
in your company.
you cannot force it, by writing "Have good teamspirit, dammit!"

And my first impression was pheew they must have some work
environmental issues?!

You are far to longwinded when explaining reasons, and they also come
out repeatabingly.
Which is annoying.

mic

In part it is cultural. I've worked with a lot of Indian developers,
and they are far more self-disciplined than American developers,
therefore willing to be spoken to sharply.

When I traveled on business, I had an executive stay place to myself.
My Indian colleagues have to share rooms, sometimes three men in the
same room.

At IBM Waterbury I drove to work by myself. My Indian colleagues car-
pooled like men of my father's generation, saving resources and the
environment.

In American companies of the 1970s, I was criticised for working too
hard and making older employees look bad. In some cases they were
blowing coke on the job, and I could never get questions asked in a
timely fashion: people were seldom at their desks. Firings were so
rare that the employees would have a huge party for the firee.
Needless to say, companies with Indian developers don't have to put up
with this crap. Nor should they!

In Shenzen, my Chinese co-workers would come in on Sunday to (for
example) generate sets that yacc could not generate by manual
analysis. In Silicon Valley, American developers would claim that yacc
was broken.

Indian (and Chinese) developers are enthusiastic, curious, and insist
on quality, as does the OP.

That's the upside. Here is the downside.

I have heard Indian developers criticise other Indian developers using
crude racial and caste ephitets such as "brown man" or "junglee man".
Occasionally.

The OP may be a bit of a harsh taskmaster...in a harsh world, where
people stand for three hours on trains to get to work six or seven
days a week.

The OP, and other Asian developers, needs improvement in his use of
written English.

That's all the downside I can think of. On balance I wish him well. I
take back what I said about using C. It sounds like he's writing
systems software.

 

[Tech07]

What did you expect, in comp.lang.c?

Well I didn't expect you to admit to being a heckler, that's for sure.
Secondly, I don't want anything to do with any "c.l.c political parties".
I'm here for technical information only.

 

[Tech07]

Users (of C)

Definition plz. ("god" theory is in the religious groups). Your post cut
beyond unreasonable assumption.

 

[Tech07]

Users (of C) write code. It is not unreasonable to call the code they
write "user code". It can also be called a "C program". You are
attempting to create an arbitrary distinction between "C code" and "C
code", whereas in fact there is no distinction.


What /did/ you expect me to admit to - beating my wife?'

You are not "boxed in". You are someone... old. As in: "I've used my dick,
so I am the President"?. How could you be anything else: ever been
interogated by a board room? "It ain't pretty".

"You didn't sign up for this?". I believe you. I didn't!

But, you are like the president: you used your dick.

Well you "have the vote", what else you want?

Cry me a river.

<[email protected]> demonstrates otherwise.
Something about the colour of paint on the office wall, and how windy
it used to be. If you want to play holier-than-thou convincingly, you
need to /be/ holier-than-thou.

I'm not your jesus.

 

[Tech07]

I think it would be better for you to seek knowledge (if that is
indeed what you seek)

pffft: show my IQ/EQ. Ah!! That's been filtered out in "the law"! (go
figure).

from others here.

I suggest you keep your voice to you and not impose it upon others. If you
are a "group", state so.

It seems that you read what I
write only to find ways to misinterpret it or misrepresent it.

Proof required, else STFU.

I may
be wrong about that, but that's how it looks from here.

Let's use USA law of defamation for a baseline, OK? No, let's not.

I can think
of better ways to spend my time, and no doubt you can think of better
ways to spend yours.

2nd generation <> "board the train" ?

Get out of my face.