Hi Pedro, et al..
---- [EMAIL PROTECTED] schrijft:
> Hi guys,
>
> Hi have for the past week been trying to build the VLC player with
> mingw32ce. This has been serving me to get a feeling for what is
> needed/lacking in mingw32ce. I have successfully ported/built a bunch
> of stuff, like zlib, libogg, libmad, libbidi, and freetype. I have
> built ffmpeg also without plugins, and Daniel Alm has made good
> progress on some plugins porting.
>
> On the mingw32ce side, I ended up reimplementing the time related functions,
> since they were buggy, and added among other things. Things like a stat
> function, strerror, and perror, based on GetLastError(), not errno.
> Most of the uses I've seen of perror, come after calling stdio
> functions, like fopen, and coredll does set GetLastError on error there.
>
> This leads me to the biggest frustration in porting stuff to wince:
> The famous `no errno` problem.
>
the problem indeed is that windows is lacking the errno for many calls.
You are right that there is some support.
> I got tired of doing #ifndef __MINGW32CE__ or #ifdef HAVE_ERRNO_H
> around errno stuff.
>
> I have seen different solutions to the problem, which I'll describe below.
>
> 1) define an `int errno` somewhere in the code, and an `extern int errno`
> in an errno.h file in some cecompat subdir in the project.
>
> Problems:
> Gives false sence of error handling. Eg:
> fopen ("doesnt_exist.txt", "r");
> if (f == NULL && errno == ENOENT)
> {
> // oops, this will never be reached, because fopen has no notion
> // of our errno.
> }
>
> Only explicit errno sets will be caught, since the runtime (coredll.dll)
> doesn't know a thing about it.
>
> I am looking at an easy way out, so I am looking at putting something in
> mingw32ce to solve this. If we provided an int errno in libmingwex.a, it
> wouldn't be shared across dlls, which may result in nasty surprises. eg:
>
> int function_in_dll (const char* param)
> {
> printf ("%p\n", &errno);
>
> if (!param)
> {
> errno = EINVAL;
> return -1;
> }
> return 0;
> }
>
> int function_in_app ()
> {
> printf ("%p\n", &errno);
>
> errno = 0;
> function_in_dll (NULL);
> if (errno != 0)
> {
> // oooops, dll's errno is different from the app's errno.
> }
> }
>
> The errno from the dll would have a different errno from the app, so the
> calling function would never see the errno being set.
>
> Plus, it isn't thread safe. A proper errno would have to be put into TLS.
>
> 2) Same as (1) but move int errno into a shared dll.
>
> To solve the multiple errno problem, we might move the errno to a dll, then
> it would be shared among all the apps, but I hate having an extra dependency.
>
> 3) Rewrite the code to use [Get|Set]LastError()
>
> This is what I have been doing, and it has been very, very time consuming.
> It is mostly a cycle of build, look at error, wrap in ifdefs, eventually
> rewrite, rebuild, rewind, wait, build, rewait, etc.
> Major time killer. Been doing late hours because of this :)
>
> 4) Map errno to [Get|Set]LastError() with preprocessor macros.
> #define errno GetLastError()
> #define __set_errno(X) SetLastError((DWORD)X)
> #define ENOMEM ERROR_OUTOFMEMORY
> (...)
>
> Simple, has no multiple errno across dlls problem. Still needs code porting
> to replace all the errno = X with __set_errno(X), but since __set_errno is
> somewhat of a defacto standard, and some srcs already use it, should be easy
> to
> convince the upstream maintainers of the app/lib you are porting to change
> the
> code, or accept patches in that direction.
>
>
> ---------------------------
>
> Conclusion:
>
> I like 4 the best, and I am going to give it a try.
Sounds fair to me.
I have encountered the same problems before and always resorted to writing my
own errorhandling..
i.i.r.c. the fileopen "open" can return 0 under linux as a valid handle
(stdout) but under windows that means an error.. (or something in that
direction)
>
> Any opinions/comments/requests-for-clarification/war_stories
> would be much appreciated.
>
> Cheers,
> Pedro Alves
later,
(still building cecgg, no errors yet :-)
Jan Rinze.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Cegcc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
