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

Pages: 1-4041-

Wut ? C

Name: Anonymous 2007-11-16 12:09

AviStruct* GetVideoInfo(char*file)
{
    AviStruct* MyVideo = (AviStruct*)s_alloc(sizeof(AviStruct));
    FILE*f = fopen(file,"rb");
    if (f)
    {
        unsigned int dwRate;
        unsigned int dwScale;
        unsigned int dwLength;
        fseek(f,0x84, SEEK_SET );
        fread(&dwRate,4,1,f);
        fseek(f,0x80, SEEK_SET );
        fread(&dwScale,4,1,f);
        fseek(f,0x8C, SEEK_SET );
        fread(&dwLength,4,1,f);
        fseek(f,0x40, SEEK_SET );
        fread(&MyVideo->width,4,1,f);
        fseek(f,0x44, SEEK_SET );
        fread(&MyVideo->height,4,1,f);
        MyVideo->fFps = (float)((float)(dwRate)/(float)(dwScale));
        MyVideo->fDuration = (float)((float)(dwLength)/(float)(MyVideo->fFps));
        return MyVideo;

    }
    return 0x0;
}

Name: Anonymous 2007-11-16 12:13

good joob discovering the RIFF structure

Name: Anonymous 2007-11-16 13:14

AviStruct*
GetVideoInfo(char* file)
{
  AviStruct* MyVideo = (AviStruct*)s_alloc(sizeof(AviStruct));
  fread(MyVideo, sizeof(AviStruct), 1, f);
  return MyVideo;
}

Fixed.

Name: Anonymous 2007-11-16 20:25

>>3
It won't work, noob.
if you look at the fseek, you'll see that it isn't right at the beginning of an avi file.

Name: Anonymous 2007-11-16 22:02

>>4
Arguably, you could reconstruct your AviStruct structure to have padding to account for the offset. And arguably any performance loss it causes would be insignificant since the operation which loads it is only done once per file and isn't a limiting factor.

Also, neither of you close your fucking file handle.

Name: Anonymous 2007-11-16 23:01

>>4
funny how you call him a noob for the lack of a fseek at the start but have no idea that YOU DONT NEED TO GODDAMN CAST IT TO FLOAT SO MANY FUCKING TIMES

Name: Anonymous 2007-11-16 23:14


MyVideo->fFps = (float)((float)(dwRate)/(float)(dwScale));
I lol'd

Name: Anonymous 2007-11-17 0:42

>>7

I remember coming across the following fragment of code when I was grading assignments from first year CS students:

x = 2;
x = 2; // just to make sure
x = 2; // one more time wouldn't be a bad idea

Name: Anonymous 2007-11-17 0:52

>>8

RISC processor!

Name: Anonymous 2007-11-17 2:51

>>8
he doesn't trust the compiler, he'd go far as a programmer

Name: Anonymous 2007-11-17 4:24


for(;;);
for(;;);
for(;;);
Just to make sure

>>1

return 0x0
what.

Name: Anonymous 2007-11-17 4:58

>>11
he casts shit to float constantly yet forgot to cast (void*) to 0

Name: Anonymous 2007-11-17 5:50

>>12
he forgot to desallocate his MyVideo in case the file doesn't exist
he doesn't fclose
there's extra float conversion
here's a fixed code for you
AviStruct* GetVideoInfo(char*file)
{
    AviStruct* MyVideo = (AviStruct*)s_alloc(sizeof(AviStruct));
    FILE*f = fopen(file,"rb");
    if (f)
    {
        unsigned int dwRate;
        unsigned int dwScale;
        unsigned int dwLength;
        fseek(f,0x84, SEEK_SET );
        fread(&dwRate,4,1,f);
        fseek(f,0x80, SEEK_SET );
        fread(&dwScale,4,1,f);
        fseek(f,0x8C, SEEK_SET );
        fread(&dwLength,4,1,f);
        fseek(f,0x40, SEEK_SET );
        fread(&MyVideo->width,4,1,f);
        fseek(f,0x44, SEEK_SET );
        fread(&MyVideo->height,4,1,f);
        MyVideo->fFps = ((float)(dwRate)/dwScale);
        MyVideo->fDuration = ((dwLength)/(MyVideo->fFps));
        fclose(f);
        return MyVideo;

    }
    //Could not open file
    freememory(MyVideo);
    return 0;
}

Name: Anonymous 2007-11-17 5:52

>>13
You can avoid calling fseek if your structure has the same structure of the file for the header but that would mean extra usage of memory.

Name: Anonymous 2007-11-17 5:59

>>12
You don't return (void*)0. you return NULL.

Also, f(set/get)pos, use it motherfucker.

Name: Anonymous 2007-11-17 9:26

How about checking dwRate and dwScale for zero, idiots.

Name: Anonymous 2007-11-17 9:39

Nice error checking everyone! Also I am impressed by your endian neutrality, and your capability to work on systems where an int is not 32 bits.

Maybe you could only allocate the memory if the file opening was successful? Just a little tip ;)

NIGGERS

Name: Anonymous 2007-11-17 13:41

There are piles of things wrong with >>1's code post. First, it puts main functionality inside an "if successful" branch, when obviously error handling should be in the further indented bit. Second, it pointlessly abuses fseek() to read bits and pieces of a header when a read into a byte buffer would be clearer (and a little bit faster too).

Third, and most important, it reads integers in a non-portable way. INTEGER ENDIANNESS MOTHERFUCKER, have you heard of it?

I'd do the same somewhat like this:


unsigned int uintFromFile(FILE *f, off_t offset)
{
    int n = fseek(f, offset, SEEK_SET);
    if(n != 0) goto iofail;
    uint8_t buf[sizeof(unsigned int)];
    n = fread(buf, sizeof(unsigned int), 1, f);
    if(n != 1) goto iofail;
    // assuming little-endian, i.e. RIFF byte order
    return buf[0] | (((unsigned)buf[1]) << 8) | (((unsigned)buf[2]) << 16) | (((unsigned)buf[3]) << 24);

iofail:
    if(errno == 0) {
        fprintf(stderr, "%s: short read\n", __FUNCTION__);
    } else {
        fprintf(stderr, "%s: IO failure: %s\n", __FUNCTION__, strerror(errno));
    }
    exit(EXIT_FAILURE);
    // or some other appropriate error handling mechanism   
}

This moves error handling out of the main functionality and into a reusable function (we'll assume that you'd like to read other bits from the AVI header too), and narrows down the error cases so that the caller doesn't need to bother their little noggin too much.

You could also change the prototype to int uintFromFile(unsigned int *result_p, FILE *f, off_t offset) and store the output integer in *result_p and return an error indicator (0 on success, errno on failure, for instance).

Name: Anonymous 2007-11-17 13:57

>>18
GOTO━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

Name: Anonymous 2007-11-17 14:36

>>19
Gotos in a strictly downward direction are kosher. Just ask your local rabbi. (unless he's busy welding his foreskin golem.)

Name: Anonymous 2007-11-17 15:04

>>20
What are you getting so defensive about?  Don't tell me you know, in your heart, that your code is actually the incarnation of Abelson?

Name: Anonymous 2007-11-17 15:09

>>15
You're a fucking idiot for not knowing they're the same damn thing.

NULL is a #define for (void*)0

>>13
still forgetting the fact hes returning a pointer, this isnt C++ where 0 == NULL, wait is it?

>>17
1. cant be fucked, we're all trolls here
2. tiredness
3. learning java

>>18
fail for assuming endianness, enjoy your reversed bits

plus, you should check the size of the integer via a #define as provided by the system headers then using #define to create the correct structure and function, your function adds too much overhead at runtime

Name: Anonymous 2007-11-17 16:05

>>22
Suck a cock, fool. The only thing that is assumed there is the endianness of 4-byte integers in the file, which is generally specified by the format!

The only thing wrong with the code in >>18 (why doesn't /prog/ have IDs anymore?) is that it should declare the buffer to be exactly 4 bytes long -- since the file format defines uints as 4 bytes. It's subsequently converted to an unsigned int in the return -- see the shifts and ors?

Name: Anonymous 2007-11-17 16:05

>>21
Everything on /prog/ is criticism by default. Therefore there is no "being defensive" on /prog/.

Name: Anonymous 2007-11-17 20:58

>>23
what's that? i can't hear you with that cock in your mouth

trolled

Name: Anonymous 2007-11-17 22:23

>>25
YHBT

Name: Anonymous 2007-11-18 3:29

>>26
YHBT

Name: Anonymous 2007-11-18 5:34

>>1
What coding style is that where he capitalises function/variable names?
Im a programming noob and most of the professional code I've seen on google/cpan/directx sdk uses camelback notation.

IE: getVideoInfo( char* file )

Name: Anonymous 2007-11-18 6:19

>>28
Nigger style

Name: Anonymous 2007-11-18 10:10

>>28
Get out, haskellFag.

Name: Anonymous 2007-11-18 10:17

I still wonder why people hate shitCase. It's the same as CamelCase except for the lack of the completely useless capitalization of the first letter.

Name: Anonymous 2007-11-18 12:01

>>31
CamelCase is periodic, shitCase isn't. Observe:

^/\/\/\/\/\/\/\/
NOT BEAUTY.
\/\/\/\/\/\/\/\/
NOT BEAUTY either, but at least you can make longer patterns of it.

Also, shitCase makes it look that the typist is hopelessly stuck between the convention of variables beginning in lowercase and readability.

Bottom line is, haskellSucks.

Name: Anonymous 2007-11-18 16:05

longer patterns of it
class DrugStrengthFormCountryManufacturerPharmacyCopayProductPriceFactory
{
    public DrugStrengthFormCountryManufacturerPharmacyCopayProductPrice
        getSalesOrderProductSupplierCopayDrugStrengthFormCountryManufacturerPharmacyCopayProductPrice(
            SecurityContext securityContext,
            SalesOrderProductSupplier salesOrderProductSupplier,
            Organization copay)
    {
        /* some code here */
    }
}

Name: Anonymous 2007-11-18 18:49

>>33
WorseThanFailure is made of niggers and Microsoft shills, and you're a faggot for reading it.

Name: Anonymous 2007-11-18 18:59

>>33
ENTERPRISE!

Name: Anonymous 2007-11-18 19:51

>>34
Takes one to know one, faggot.

Name: Anonymous 2007-11-18 20:18

>>36
That's a brilliant come-back, that is, especially given that the fact >>34 recognised the quote was already an admission of his own faggotry, making your post little more than an agreement.
gb2 middle school

Name: Anonymous 2007-11-18 22:16

>>33
AHAHAHA you read that shit too?

Name: Anonymous 2007-11-18 23:39

>>34
How do you recognize that excerpt from WorseThanFailure?

Name: Anonymous 2007-11-19 0:31

>>39
This has already been discussed in >>36-37.

Name: Anonymous 2007-11-19 10:39

>>28
That's shitCase, and itsUgly. Also, how the fuck will you tell a function from a variable when it's only one word? Fucking niggers.

>>31
Useless? Nigger! If you capitalize functions to tell them from variables, then what the fuck fuck is? A function? A variable? And don't give me that "verbs are for... while you use..." bullshit, I hate your retarded naming conventions and all the "software engineering" idiots who think programming can be rationalized to that point.

Also, shitCase looks like shit, is harder to transform, etc.

So the bottom line is, UseCamelCase, not shitCase, faggot. You're ugly.

Name: Anonymous 2007-11-20 8:29

ITT haskellFags

Name: Anonymous 2007-11-20 11:23

>>41
functions are variables too. you don't need to tell them apart.

Name: 31 2007-11-20 11:43

>>41
 I just can't understand why you think there's a need to separate functions from variables using some ``naming convention''; I've never had such problem with any language, ever.

I just use whatever naming convention is used by the language's standard library, and several languages happen to use shitCase without any problems, which has led me to believe that the rabid shitCase haters are just C++ kiddies or mindless [Java,Haskell,Obj-C,whatever] bashers who desperately try to rationalize their worthless opinions.

Name: Anonymous 2007-11-20 11:50

Just use the Hungarian naming convention and stfu goddamnit.

Name: Anonymous 2007-11-20 12:13

>>43
The fact they're variables is absolutely true. However, I prefer to separate applicable variables from non-applicable ones using some naming convention. On Python (one word, the forced indentation of code) this means I'll CamelCase all variables bound to functions (be them anonymous or uh... nonymous), classes and other objects which happen to be callable (property __call__ defined and set to an applicable value). For example, I'd start defining map like:
define Map(F, *iters):
For very basic, non-application utilities such as map, I make an exception, though, and stay with lowercase.

>>44
If you don't understand naming conventions, then why do you adhere to them, and shitCase of all of them?

>>45
moronanon45.methDoAction(actnSTFU)

Name: Anonymous 2007-11-20 12:56

reach satori

Name: Anonymous 2007-11-20 17:04

>>43
No, no, no. Variables are simply functions that no longer require arguments.

Name: Anonymous 2007-11-22 9:22

No no no no, serious business!

Name: Anonymous 2007-11-22 9:27

>>43,48
No, no, no, no. It depends solely from the definition given from the language spec.

Name: Anonymous 2011-02-04 15:07

Name: Anonymous 2011-03-31 22:22

 
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -