Conversation
At earlier point e_os.h was omitted from a number of headers (in order to emphasize OS neutrality), but this affected o_fopen.c, which is not OS-neutral, and contains some DJGPP-specific code.
Some platforms, cough-DJGPP, fail to compile claiming that requested alignment is greater than maximum possible. Supposedly original alignment was result of an attempt to utilize AVX2...
| # include <windows.h> | ||
| # endif | ||
| # ifdef __DJGPP__ | ||
| # include <unistd.h> |
There was a problem hiding this comment.
Should we just take away that config parameterattribute?
There was a problem hiding this comment.
I don't follow... Do you mean unistd (that is customarily assigned to <unistd.h>)? If yes, then in long run, yes, totally. Even though there might be kind of a chicken-n-egg problem. I mean if you want make it #ifdef conditional, then you you'd probably want to use POSIX_something, but those customarily come with unistd.h. Well, it's not like they are defined in unistd.h, but unistd.h would be number 1 choice to get them without thinking too much about what system is it. Though there is one predefine that is quite reliable, __unix__/__unix... In case you wonder, if it's defined by djgpp compiler? Yes, Cygwin? Yes. Can you guess if "MSYS" compiler does? "MinGW" cross-compiler? Answers are of course "yes" and "no". This by the way reliable way to tell apars "native" and "hosted" that are discussed in updated NOTES.WIN...
But in either case here, in o_fopen.c it would still be DJGPP-specific. In normal case this module would require stdio along alone. This is non-POSIX thing. And it's only DJGPP that needs that POSIX-y pathconf to take a decision.
There was a problem hiding this comment.
Though there is one predefine that is quite reliable,
__unix__/__unix... In case you wonder,
Well, there is one that doesn't follow the pattern. Can you guess which one? Vendor that always has to be special... Anybody?
There was a problem hiding this comment.
I should mark my side notes explicitely as such... But to answer your question, mine was about the config attribute unistd, which is usually assigned "<unistd.h>", except on nextstep...
There was a problem hiding this comment.
So many choices... MSFT... Apple ... don't keep us guessing, @dot-asm
There was a problem hiding this comment.
I meant can you guess one that you would totally expect to pre-define __unix__ in compiler. One that is equipped with Bourne shell, has find, grep, ls, ... and even has <unistd.h> that defines POSIX_things... It can't be Windows... But of course it's Apple, you guessed it.
At earlier point e_os.h was omitted from a number of headers (in order to emphasize OS neutrality), but this affected o_fopen.c, which is not OS-neutral, and contains some DJGPP-specific code. Reviewed-by: Rich Salz <[email protected]> (Merged from #5708)
In other words no-sock DJGPP build should suppress syslogging. Reviewed-by: Rich Salz <[email protected]> (Merged from #5708)
Some platforms, cough-DJGPP, fail to compile claiming that requested alignment is greater than maximum possible. Supposedly original alignment was result of an attempt to utilize AVX2... Reviewed-by: Rich Salz <[email protected]> (Merged from #5708)
4 participants
In case one wonders, it does build with no-sock and passes some rudimentary tests.