HELP please

what is wrong with my program? its supposed to process arguments but it doesnt.
void output(char *fuckyou);
int main(int argc, char **argv) {
  int i;
  for(i = 0; i < argc; i++) {
    output("SHIT");
  }
}

you forgot to code output

>>2
no i didnt.
it works by the way.

void output(char *fuckyou);<--accepts only pointers


__________________
Orbis terrarum delenda est

Try this:
inline void output(char const text[]){puts(text);}
int main(){output("abc")}


__________________
Orbis terrarum delenda est

>>4
Learn C please.
>>1
How about you do something with i, argc or argv (i.e. process them) instead of just output()ting "SHIT" for each one?
That's why it's not processing them. Because you didn't tell it to.

>>6
The SHIT thingy is just a placeholder, it desnt even enter the loop, that is my problem

I compiled my program without libc, is that a problem?

>>7
Fuck off, ``faggot''.

>>7
Have you given it any arguments?

>>10
Yes, lots of them.

>>11
Maybe you should be nicer to it.

>>12
nope, doesnt work either.

>>13

Judging by your response, you don't know how to be nice.

>>14
I dont have to know, i got man pages.
nice [OPTION] [COMMAND [ARG]...]

>>15

That fact that it doesn't work is proof that you do have to know.

i++
I found your problem. You're a Sepples programmer.

>>17
Scuse me?

Is it even possible that this might be a error of my side? Or must the compiler simply have fucked up?

Here's a hint: if you want people to troubleshoot your code, post all of your code instead of just the bit you think is fucking up. You didn't manage to figure out the problem on your own, so chances that you'll be able to successfully identify the right bits of code to post yourself aren't that great.

Bonus hint: it's never a compiler problem.

>>18
He mena i = i + 1

>>19
Ultra mega bonus hint: ``it doesn't work'' means fuck all.

>>19
I have a LOT of code, so posting here is not really an option.
And seriously now what else could it be?

>>20
Or maybe ++i, the idiomatic way to increment a variable that K&R uses throughout.

>>22
Perhaps something before that loop that you may have gotten rid of?

>>22
Random guess: your output function. Or a return or exit before the loop. Or something that clobbers the value of argc before the loop.
You shouldn't have ``a LOT of code'' if tracking down a problem like this is beyond you.

>>22
Pastebin.com <--learn to use it


__________________
Orbis terrarum delenda est

>>24
No, there is nothing before that loop.
Parameter procession is the very first thing this program is supposed to do.

The functions after the loop work fine tough. And GCC does not complain about anything in this function.

>>27
Replace output with a more sensible alternative, like printf or puts.

(Depending on what kind of arguments you're processing, look into getopt as well; that's neither here nor there, though.)

>>28
ld refuses to link glibc and i dont know of any other output functions.

And i am dead sure output works as intended.

>ld refuses to link glibc
Lunix developer using "newest glibc"?

__________________
Orbis terrarum delenda est

>>29
ld refuses to link glibc
See, that's a bit of information that would have been useful from the very beginning.

>>31
How is that relevant?

>>32
When your program doesn't work as intended and your linker isn't producing the binaries you expect without error? Hmm.

>>33
It does produce the binaries as expected, it just doesnt work with libc.so specificly.

>>34
You need either:
1. fix your glibc
2. use alternative like http://www.fefe.de/dietlibc/
3. switch to easier language like Python/Ruby/JavaScript

__________________
Orbis terrarum delenda est

>>35
Thanks FV, i will try this alternate lib you linked me too.

Hey is there any reason that Allegro's masked_blit() suddenly fails to transparentize 255,0,255?

Cool thread btw.

void masked_blit(BITMAP *source, BITMAP *dest, int source_x, int source_y, int dest_x, int dest_y, int width, int height);
Like blit(), but skips transparent pixels, which are marked by a zero in 256-color modes or bright pink for truecolor data (maximum red and blue, zero green), and requires the source and destination bitmaps to be of the same color depth. The source and destination regions must not overlap. Example:

      BITMAP *hud_overlay;
      ...
      /* Paint hud overlay on the screen. */
      masked_blit(hud_overlay, screen, 0, 0, 0, 0,
          hud_overlay->w, hud_overlay->h);



If the GFX_HW_VRAM_BLIT_MASKED bit in the gfx_capabilities flag is set, the current driver supports hardware accelerated masked blits from one part of the screen onto another. This is extremely fast, so when this flag is set it may be worth storing some of your more frequently used sprites in an offscreen portion of the video memory.

Warning: if the hardware acceleration flag is not set, masked_blit() will not work correctly when used with a source image in system or video memory so the latter must be a memory bitmap.


__________________
Orbis terrarum delenda est

>>32
It demonstrates your build environment is fucked beyond redemption. Fix it.

>>35
Hey the lib you linked too works, thanks a thousand times. But my program still doesnt work as intended.