Search:

I guess he's talking about short ints.

Since when there are 16 bits floats?

You're wrong. The OP code is wrong, but your example is not. The code:


x=y++;

is perfectly fine and it means:


x = y;
++y;

IMO on smp systems you still need at least an atomic_test_and_set function to do that.

#include <stdio.h>
#include <stdlib.h>

void test_function(int ***);
int *fill();

int main()
{
int **p=NULL;
test_function(&p);

IMO there's no point in doing the typedef of struct console either, unless he wants to create an opaque type(which wouldn't make it necessary, but sometimes it's used).

You're doing a typedef of struct "nothing" to console.
And the first typedef doesn't work.
An example that works:


#include <stdio.h>

struct console;
typedef struct console *console_ptr;

Among the other reasons, try this code to get an hint:


#include<stdio.h>

int main(void)
{
printf("sizeof('a') = %d\n", (int)sizeof('a'));
return 0;
}

There are some errors. For example, you're putting words 6 chars long in an array[6], so there's no place for the terminating \0.

Also, talking about style, it should be like this:

...

I know, it's -std=c99, but I usually use -std=gnu99. It's still like that mostly because of problems with dinamic arrays(if I remember correctly).
No, I didn't remember correctly: Status of C99...

Looking at C99 right now is not as important as using a good c compiler like gcc. (If you use windows, try mingw, even if probably, for windows, the intel compiler is better[not sure though])

2) I didn't say that it's a major optimization that will skyrocket the performance of code, but it's still an optimization. Is that the main reason why I prefer it? No, the main reason is that it...

I've already put that into the code, it's getchar()(for example).

1) It's very simple: system passes its string argument to the shell for execution in an implementation-defined way. So for example, you could end up on a system where there's no "PAUSE" to call, like...

If you've got a unix OS, try using cdecl.

#include<stdio.h>

int main(void)
{
for(int counter = 1; counter <= 10; counter++)
{
printf("The value of the counter is now %d.\n", counter);

if(counter == 3)
printf("Hey damned,...

You're still wrong. The fact that architecture x may not be available among the architectures supported just means that the library hasn't been ported to that architecture. Again, that can be said...

Again, this is completely irrelevant to the previous discussion and I never said that. It just seems to me that you're unable to admit that you were wrong.

Right, I didn't notice it.

void ValidatePhoneNumber(char *phoneNumber)
{

if (phoneNumber[4] != " ") {
phoneNumber[4] = " ";
}

}

That's completely unrelated to the concept of portability. Being standard and being portable are 2 completely different concept.

I can simply use what he said about glib with the c standard library and prove that he's wrong:

What exactly do you think "the c standard library" does internally? It calls platform-specific...

No, your definition of portability is wrong. By your definition, not even the c standard library would be considered portable.

Well, I think it can be done in a portable way through glib.

Yes, I misunderstood, sorry.