unfixable due to API freeze;

if your system defines 'read' as a macro; you're going to be screwed
anyway IMHO.

Michael, I'm serious:

> grep '[^f]truncate.*truncate64' /usr/include/unistd.h 
#pragma redefine_extname        truncate        truncate64
#define truncate                        truncate64

All libc functions can be macros, possibly excluding some longjmp
related ones.  I seem to remember that quite a lot of glibc users
got caught red-eared when glibc made printf a macro.

Have a look at http://bugzilla.gnome.org/show_bug.cgi?id=71184


Conclusion: the code is buggy.  Reconsider WONTFIX.  At least put
on list of things to fix when API changes are allowed again.  In the
long run "standards don't apply to me" is not viable.

Sigh; it's really not very possible to fix this one;

Can you take the discussion onto gnome-hackers so we can get some more
errudite input.

I don't really want to change every Stream/Storage read/write to
something else (what ?) - I mean, it just sucks utterly.

It's really not clear to me what to do; I imagine the real solution is
for whomever creates these defines to define their read thusly:

#define read(a,b,c) foobarbrokenread(a,b,c)

Rather than just screwing with the 'read' name globally.

Did this discussion ever happen?

Yes and no.  In one of this bugs' sisters, it was make pretty clear to
me that people don't feel the standard applies to them in this matter.
(Apparently writing "Read" is much harder than writing "read".)

'Read' breaks the method naming convention; perhaps readBytes or
something would do - but that breaks the API freeze - so we just can't
win.

So - we get to choose whether we screw people with broken OS' that do
stupid things with parameterless macros, or whether we break API
compatibility for every program that uses Stream;