First off: 64-bit filesys support would require a (minor?) API change; there's been a similar size_t move in the past (partly rolled back IIRC) and several 'int' or 'long' arguments should be turned into off_t types indeed, irrespective of the typedef used to define that type. Several systems have llseek() and friends, but the request for 64-bit filesystem support means 1) an API change (parameter types of most BIO functions change int size; remember all the BIO_read()s share the same arg setup, etc., so what you do for filesystem, you implicitly impart on the rest as well!) 2) some additional coding/configure-script-detection work on the inside.
Doable, but it takes time and from the look of it, there's not a lot of /that/ to go around. For the remainder, which is veering OT, when you feel it's TL;DR: it was Rousseau IIRC who said when the world would perish in the advent of Armageddon, the Netherlands would /still/ be lagging 50 years behind (so I don't worry, as I'm Dutch and I'll be long gone by then). Anyway, if you worry about 'portable', do like the Dutch and lag maybe 2, 3 decades behind in what /can/ be had, standards-wise, and what you /must/ have on your target platforms. Anything less antiquated would merit a 'thank you' and a config setting. Enjoy your e_os.h + e_os2.h, and probably some others as well. - On Thu, Oct 7, 2010 at 2:45 AM, Darryl Miles < darryl-mailingli...@netbauds.net> wrote: > > In practice the only platforms with shorter than 32bit sizeof(int) are less > than 32bit CPUs. I'm not even sure is OpenSSL tries to support smaller than > 32bit CPUs out of the box you really have to try hard to find one in the > embedded world since 32bit is so cheap now. OT: Not exactly. One example is the (yeah, this is old gunk, but it's good gunk and used by people I know who do MC68K embedded work) BorlandC & PureC MC68K compilers, where sizeof(int)==sizeof(short)==2 and sizeof(long)==4. In terms of 'developer count' that would constitute maybe, ahh, .05% of the total 32-bit developing populace, but it goes to show you can't trust anything re bitsize for integers in the pre-C99 era. (The mentioned compilers are both ANSI/ISO, but C99 wasn't even a dream yet at the time these were incubated.) And, no, OpenSSL hasn't been ported to that compiler combo recently AFAIK, nor is it expected to as today we can assume x86+PPC+ARM+...others/niche.... when it comes to networked hardware. Hence the [OT]. > Many others these days. How shall I put this... in Embedded Development County, 'upgrading' is not a much sought after activity; most places I visit have spent countless agonizing hours on finding and setting up a nice dev rig that works well and 'upgrade' experience isn't all that much of a happy experience, both monetary and functionality/toolchain-wise. Relevance? OpenSSL is used in embedded rigs quite often; the compilers in there, even when they are called 'gcc', are not to be expected to be 'bleeding edge' builds or close to that. Then there's a lot of NOT-gcc compilers out there that 'do' OpenSSL just fine (with a tug here and a bit of a bend there) and those don't always offer the entire adorable fullness of the POSIX header set&content (including lacking such things as a system-defined off_t ), let alone the existence of a C99 stdint.h. >Isn't this an ANSI requirement, ah well, poor compiler users what standards do they conform to then ? stdint.h ~ C99 IIRC. stdio+stdlib are C89. My printed copy of C99 is in a box in the garage somwhere and my memory is fading, if it was any good at all to begin with... sigh. Besides, if you would be cynically inclined, then you'ld be laughing very hard when you knew the number of 'portable' packages out there that require (and don't check their configure scripts) a unixstd.h, which is... well, not C89, anyway, so the lacking stdint.h is a very minor thing. Sure the whole bloody mess is nicely soluble in a 1-2-3 step dance of 1-config, 2-e_os.h/e_os2.h hacking, and 3-extra sauce, and why the heck would the UNIX/Win majority care anyway, but you can get away (IMO) with requiring everyone to have C89+basic POSIX+stdint.h and who don't have that ready can do their own specific stdint.h and other config bits through a bit of e_os / e_os2 hooking/hacking. I've done the latter several times when porting UNIX/Win code to embedded platforms and it works out well. Not as fast as instant noodles, but doable. 'basic POSIX' I say? WTH? That'd be: filesystem: yes. (If you don't have it, fake it, where needed. Expect the driver to cough up blood when you go past the 2GB-per-file mark. Pay tribute to your deity when it doesn't.) ACL? forget it. (this includes UNIX filesystem access control games) date/time: okay. fake the TZ s*** when you're doing UTC-only; if you don't you're in for 7th level Hell anyhow (daylight saving changes vs. code in *ROM*? Too-da-loo, folks!) signals: no way. (not the old-fash signal() and not the 'modern' sigaction(), thank you) threads: if you must... (done a pthread port a ways back; just remember those pthreadid's aren't always an 'int' so don't cast them that way: see the Win32 pthreads port for example) ... did I miss anything... :-S Anyway, the point: when you put your requirements down and they want more then the above, you implicitly ditch several systems; granted, those'll be all in the tail of the system::developercount Poisson distribution, so economic choice may be to let those fend for themselves. Unless, of course, you're one of those who have those boxes around or have a client who's got them, in which case you're going to be the porter. <double meaning intentional> ;-) As a development core team you can decide to require a more-or-less C99 minimum (though I'd steer clear of the new keywords (reserved words) in C99 so as to allow one to 'backport' the goods to a C89 compiler when the need arrises), and that is fine as long as that is a conscious decision where you've weighted the merit pro and con. I and others like me can always do those 'backports' when the codebase isn't hugging the latest & greatest all to closely, which translates to providing configure-able header files or #include 'hooks' in there so one can inject their own C99/system fake without the need to clutter the code throughout. In case of a library, such as OpenSSL, remember there's TWO interfaces to any lib: front AND back. Almost everyone will focus on the 'front' one, i.e. the documented API, but from a porting perspective the 'backside' is much more important. An (older) OpenSSL port I did had to race through the entire codebase using some awk scripting to filter out all those lovely 'standard library calls' in there, such as printf() -- ever printf()d to a single LED? -- and replace them by 'wrappers' so that I had total control over in- and outgoing at all times. When this sounds like a rant, maybe it is. I hope not. I intended it more as a note of awareness. There IS one boon to be had: since the whole Linux/BSD/GNU/etc. thing is a kinda free-for-all, embedded hardware tends to use this s/w set more and more, which means implicit C99/gcc and most of the other bits. Which makes the Win32/64 Microsoft community the one seem lagging behind now (as MSVC up to and including 2008 isn't C99 compliant; I don't know about 2010 as I haven't used that one yet). -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 --------------------------------------------------
