>>18
Serious it may be - but not helpful and at most theroretically correct, mentioning experience being the exception.
With regards to the original question why C programmers like to use abstracted datatypes, its Good Practice. I have programmed systems where the C type "int" was 8 ( Z80 ), 16 ( 68k ), 32 ( ARMv4/x86 ) and 64 ( AMD64 ) bit. Now for the Z80 all hope was lost as its compiler had no 32 bit data type but the rest had one. The problem is that a 32bit integer is "long" on 68k which is 64bit on AMD64 so you typedef or #define a datatype that says "32bit integer" and #ifdef it in a single location. I also noticed in 2003, when i got myself an Opteron from AMD running 64bit stuff, how many programmers used the "long" datatype as a 32 bit Integer and did 32bit arithmetic on them, which caused a lot of grey hair for me. So using stdint.h or your own typedef'ed datatypes help create portable code.
As for typedef being bad i strongly disagree for structs but agree for unions ( which i think are ok if being a member of a struct ). The struct keyword should in my opinion only be used when the type definition of the struct is not available. A typedef helps to generate clean code. The mentioned namespace problems are minimal, given seperate header files for modules and interfaces to libraries.
For the specific example of web sites giving different opinions about the volatile keyword, consider the following code:
[ volatile ] int i_break = 0;
void possibly_infinite( void )
{
while( i_break == 0 )
{
}
}
where i_break may be decalared volatile. If it is not volatile the following code is generated by a popular GNU C compiler:
.globl possibly_infinite
possibly_infinite:
move.w i_break,%d0
.L3:
tst.w %d0
jbeq .L3
rts
while when its volatile:
.globl possibly_infinite
possibly_infinite:
.L3:
move.w i_break,%d0
jbeq .L3
rts
As you can see the loop may exit if i_break is declared volatile. This sort of synchronization is lockless and the code does not depend on an operating system supplying such functions. While on modern multi-core systems, for CPU runtime reasons, such constructs have only use as a pre-check condition and then, if the integer would be polled repeatingly, falling back to the operating system to do proper signalling, they are still valid and if used correctly quite handy.
If
>>17 had understood the articles he would have noticed that they are about different things. Those he deems correct argue about exclusive access to a resource while those he sees as incorrect are describing the use of the volatile keyword correctly.
>>23
Sure is samefag in here.