Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

ENTERPRISE UNICODE DETECTOR AND READER

Name: Anonymous 2012-01-12 20:35


#include <stdio.h>

int main(void) {
  char buff[256];
  char c;
  FILE *f;

  f = fopen("filename", "r");
  c = fgetc(f);
  if(c < 0) {
    fclose(f);
    system("type filename > filename.tmp");
    f = fopen("filename.tmp", "r");
  }
  else {
    rewind(f);
  }

  while(fgets(buff, 256, f) != NULL)
    puts(f);

  fclose(f);
 
  return(0);
}

Name: Anonymous 2012-01-12 20:58

It's undefined bevahior

Name: Anonymous 2012-01-12 21:01

>>2
no

Name: Anonymous 2012-01-12 21:05

>>1
    system("type filename > filename.tmp");
Not portable, therefore not enterprise

Name: Anonymous 2012-01-12 21:46

No buffer overflow prevention, therefore highly exploitable. What if ``filename'' was malicious machine code and you overflowed the buffer, causing malicious machine code to spill into the saved call point in memory, causing the code to run when the function returned? You're screwed.

Name: Anonymous 2012-01-12 21:48

>>5'
>fgets(buff, 256, f)
>(buff, 256, f)
>256, f)
>256,
>256


What the fuck are you talking about?

Name: Anonymous 2012-01-12 21:53

>>5
What if the C implementation didn't use a single stack that retardedly places the return address at the point just past the end of the local variables?

Name: Anonymous 2012-01-12 22:15

>>5
C doesn't have a concept of stack, you should probably go back to /g/

Name: Anonymous 2012-01-12 22:16

>>5
Also, wtf do you think the 256 means?

Name: Anonymous 2012-01-12 22:17

>>1
You've got a possible memory leak in

c = getc(f);

Name: Anonymous 2012-01-12 22:18

>>9
Dunno. Is programming weenie would refer to 256 as a magic number.

Name: Anonymous 2012-01-12 22:19

>>10
wat

Name: Anonymous 2012-01-12 22:19

>>11
Thank you captain caveman.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-12 22:21

>>12
What's the return type of fgetc()?

Name: Anonymous 2012-01-12 22:22

>>12
You gotta check for NULL.

Name: Anonymous 2012-01-12 22:23

>>14
Dang, you're absolutely right. Although any reasonable implementation would simply cast it to a char though.

Then again, that is probably easier implemented on a little-endian machine than on a big-endian.

Name: Anonymous 2012-01-12 22:23

>>15
No

Name: Anonymous 2012-01-12 22:25

>>15
If you by NULL mean EOF, then yes.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-12 22:26

>>18
NULL and EOF are two different things.

Name: Anonymous 2012-01-12 22:29

>>19
That was my point.

Name: Anonymous 2012-01-12 22:31

>>17
C99 7.19.5.3.8 The fopen function returns a pointer to the object controlling the stream. If the open operation fails, fopen returns a null pointer.
So what happens if fopen() returns a NULL pointer and you call fgetc() on it?
C99 7.1.4.1 Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.
The Standard provides no exceptions for fgetc(), so it's undefined behavior.

Name: Anonymous 2012-01-12 22:32

undefined behavior

Name: Anonymous 2012-01-12 22:33

>>21-22
Ironically, that's what >>2 said.

Name: Anonymous 2012-01-12 23:43

>>14
You're right. I meant to declare c as an int because that's the return type of fgetc, but I forgot. Other than that it's quality code.

Name: Anonymous 2012-01-12 23:45

Whatever

#include <stdio.h>

int main(void) {
  char buff[256];
  int c;
  FILE *f;

  if((f = fopen("filename", "r")) == NULL) {
    perror("fopen");
    return(-1);
  }
  c = fgetc(f);
  if(c < 0) {
    fclose(f);
    system("type filename > filename.tmp");
    f = fopen("filename.tmp", "r");
  }
  else {
    rewind(f);
  }

  while(fgets(buff, 256, f) != NULL)
    puts(f);

  fclose(f);
 
  return(0);
}

Happy now?

Name: Anonymous 2012-01-12 23:45

That's not enterprise, retard.

Post some Java design patterns.

Name: Anonymous 2012-01-13 0:07

>>9
The number bytes to read

Name: Anonymous 2012-01-13 0:09

>>8
You should probably use try gdb

Name: Anonymous 2012-01-13 0:13



#include <stdio.h>

int main(int argc, char *argv[]) {
  char buff[256];
  int c;
  FILE *f;

  if(argc<2) return -2;
  if((f = fopen(argv[1], "r")) == NULL) {


How is it detecting unicode? >> "if(c < 0)" ?

also, why type file > file.tmp ?

Name: Anonymous 2012-01-13 0:17

>>29
I think it's a joke about how CMD.EXE replaces all Unicode characters with question marks, hence the type command.
TYPE as in DOS's version of cat, not the Unix command

Name: Anonymous 2012-01-13 0:21

Err, lol

Name: Anonymous 2012-01-13 0:47

>>29
I was supposed to remember to remove("filename.tmp") so as to in effect read the unicode file without altering the original.

The Byte Order Marks of all unicode files have negative ASCII values.

Name: Anonymous 2012-01-13 6:20

>>25
return isn't a function

Name: Anonymous 2012-01-13 6:28

>>33
Neither is sizeof, but people treat it like one anyway. Who cares?

Name: Anonymous 2012-01-13 6:29

>>34
Well, I care.

Name: Anonymous 2012-01-13 6:33

>>35
Stop caring.

Name: Anonymous 2012-01-13 6:38

>>36
No.

Name: Anonymous 2012-01-13 6:40

Name: Anonymous 2012-01-13 7:00

if is not a function.
do is not a function.
while is not a function.
sizeof is not a function.
(a + b) * c is not a function.
Since when do parenthesis imply functions?
Fucking autists.

Name: Anonymous 2012-01-13 7:07

>>39
It's not the parenthesis you stupid sack of shit, it's the spacing. Read K&R you dumb Jew.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List