Quote:
Let me try to explain the fopen/raydium_file_fopen problem with a simple example. ManiaDrive stores player's solo times in a file named "mania_drive.state". When ManiaDrive opens this file, it must be with fopen() and not raydium_file_fopen() since we don't want this file being downloaded with R3S. It's a "local only file".
Then use fopen()

Nobody ever said "don't use fopen() at all" but it shouldn't be used to open media files anymore.
Quote:
I'm not saying that there's nothing to do here to get a clearer situation (like a new letter for the 'mode' : raydium_file_fopen("toto.tri","rwL"), with 'L' wich stands for 'local only', why not), but only wanted to warn you about the actual way to do.
Nice idea, should be fairly simple to add in raydium_file_fopen(). This would allows a "Never ever use fopen() in raydium" statement in the docs

Moreover, I think the example you give should work with raydium_file_fopen() because as the file is not on the repository, it will just fail (after a timeout, maybe). So no need to worry here, we just have to pick up a method

(I like the "L" mode because it allows a coding guideline)
Quote:
About coding style, [...] the main idea is to keep code readable. I think (but may be wrong) that Raydium is almost OK with this last point.
Of course. My main question when I look at the code is "why indent if, for, ... blocks, but not function bodies ?" On the whole I'd say the indentation, although readable, seems a little slack. That's why I used auto-indent and screwed the file...A friend hinted me about defining a config file for indent (the command line tool) to define a common style. Seems a bit complicated here, but the idea is there : we should define a coding style.
Quote:
I'm not against applying a strict style to Raydium, but (1) it must be done as a separate commit
Of course.
Quote:
and (2) we probably need a few *INDENT-OFF* (errrk

) tags as, IMHO, GNU style is not always perfect, far from this

Don't know exactly what you meant here (INDENT-OFF ?), but GNU style isn't perfect in my opinion, but it is a standard and many editors will indent your code according to it (emacs and vi for starters, but I guess anjunta or kdevelop can/will do the same). On a related note, you are certain the syntaxic coloration won't get screwed (as it is often currently the case with emacs).