[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> In fact, I'm not really happy with UBUFFERS, for the same reason I'm not
> happy with uconvert: using them is too complex. It's OK when you
> have tight speed or memory limitations to trade simplicity for
> optimization, but for the general case I'd prefer something easy to use
> and error proof.
I partially agree: using uconvert() can be complex, especially when you have
to keep track of several tmp buffers. That's why I think user programs shoud
use native strings. However, for internal library code, uconvert() seems to
me a good compromise.
> If the mode errors are not caught, i think the program will crash with
> the next read or write, and the programmer may have hard time fixing the
> problem. And for a partially written/read file, the program behavior may
> seem random, making the fix even harder.
If we were talking about a "true" API function, I wouldn't mind of course.
But I think the pack_fdopen() can't be considered as a "true" API function,
hence I labelled it "low-level" in the docs. When a programmer decides to go
with low-level stuff, I think he must be prepared to cope with less
error-checking (and extensively read the docs).
> Besides, I wanted pack_fdopen to mimic fdopen behavior.
That's the problem: pack_fdopen() expects a POSIX file descriptor and it's
the only public function in the whole library to do that. Ok, the packfile
module itself is written on top of POSIX functions, but so far Allegro has
been agnostic and hasn't exposed any dependency on a particular standard.
I even wonder if we shouldn't make it an internal function (exported though
because some utilities like exedat.c may want to use it), namely
_pack_fdopen().
> Thanks for the info. Sorry for breaking compilation.
No problemo :-)
MSVC seems to follow more or less the ANSI/ISO C naming convention: putting
an underscore before any non ANSI/ISO C functions of the libc.
--
Eric Botcazou
ebotcazou@xxxxxxxxxx