From: Keith M. <kei...@us...> - 2006-12-13 21:31:04
|
Hi All, Just ran into a minor glitch, using `lseek()'; a module compiled fine with my native Linux GCC, but bombed on `SEEK_SET' undefined, with i586-mingw32-gcc. POSIX *requires* that `SEEK_SET', `SEEK_CUR' and `SEEK_END' all be defined in `unistd.h', which I'd dutifully included, as required to use `lseek()': http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html http://www.opengroup.org/onlinepubs/009695399/functions/lseek.html Problem is, the above three constants are *not* defined in *our* `unistd.h'; they *are* defined in `stdio.h', which is where M$ put them, and in fact, is an alternative location also required by POSIX: http://www.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html I'm thinking we should duplicate the definitions in `unistd.h', perhaps with an `#ifndef _STDIO_H_' guard, as my Linux GCC has them. Any comments? Regards, Keith. |
From: Brandon S. <br...@oq...> - 2006-12-13 21:37:23
|
that sounds like a good way around it without breaking anyone. B On Dec 13, 2006, at 1:38 PM, Keith Marshall wrote: > Hi All, > > Just ran into a minor glitch, using `lseek()'; a module compiled > fine with my > native Linux GCC, but bombed on `SEEK_SET' undefined, with i586- > mingw32-gcc. > > POSIX *requires* that `SEEK_SET', `SEEK_CUR' and `SEEK_END' all be > defined in > `unistd.h', which I'd dutifully included, as required to use `lseek > ()': > http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html > http://www.opengroup.org/onlinepubs/009695399/functions/lseek.html > > Problem is, the above three constants are *not* defined in *our* > `unistd.h'; > they *are* defined in `stdio.h', which is where M$ put them, and in > fact, is > an alternative location also required by POSIX: > http://www.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html > > I'm thinking we should duplicate the definitions in `unistd.h', > perhaps with > an `#ifndef _STDIO_H_' guard, as my Linux GCC has them. Any comments? > > Regards, > Keith. > > ---------------------------------------------------------------------- > --- > 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 > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ea...@us...> - 2006-12-13 23:28:19
|
Quoting Keith Marshall <kei...@us...>: > > I'm thinking we should duplicate the definitions in `unistd.h', perhaps with > an `#ifndef _STDIO_H_' guard, as my Linux GCC has them. Any comments? > Hmm... Revision 1.8 of io.h removed the inclusion of stdio.h which is also supposed to contain these definitions. Io.h is included in unistd.h because it is most like the UNIX counterpart. I'm thinking that this removal of stdio.h from io.h wasn't a good thing. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Keith M. <kei...@us...> - 2006-12-14 00:27:52
|
On Wednesday 13 December 2006 23:28, Earnie Boyd wrote: > > I'm thinking we should duplicate the definitions in `unistd.h', perhaps > > with an `#ifndef _STDIO_H_' guard, as my Linux GCC has them. =A0Any > > comments? > > Hmm... =A0Revision 1.8 of io.h removed the inclusion of stdio.h which is > also supposed to contain these definitions. =A0Io.h is included in > unistd.h because it is most like the UNIX counterpart. =A0I'm thinking > that this removal of stdio.h from io.h wasn't a good thing. Pulling in all of stdio.h, via io.h or otherwise, just to get three constan= t=20 definitions required for unistd.h, does seem a bit like overkill. The Linu= x=20 headers do *physically* reproduce the three constants in question, in both= =20 unistd.h *and* stdio.h; perhaps that would also be the cleanest solution fo= r=20 our needs. My Linux headers do have the `#ifndef' guard in unistd.h, but not in stdio.= h;=20 since the definitions must be identical in both places, I don't really see= =20 the need for the guard in either. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-12-14 13:12:38
|
Quoting Keith Marshall <kei...@us...>: > On Wednesday 13 December 2006 23:28, Earnie Boyd wrote: >> > I'm thinking we should duplicate the definitions in `unistd.h', perhaps >> > with an `#ifndef _STDIO_H_' guard, as my Linux GCC has them. Any >> > comments? >> >> Hmm... Revision 1.8 of io.h removed the inclusion of stdio.h which is >> also supposed to contain these definitions. Io.h is included in >> unistd.h because it is most like the UNIX counterpart. I'm thinking >> that this removal of stdio.h from io.h wasn't a good thing. > > Pulling in all of stdio.h, via io.h or otherwise, just to get three constant > definitions required for unistd.h, does seem a bit like overkill. The Linux > headers do *physically* reproduce the three constants in question, in both > unistd.h *and* stdio.h; perhaps that would also be the cleanest solution for > our needs. > I was trying to point out that stdio.h was removed from io.h but based on comments in stdio.h someone made a decision to include stdio.h into io.h and remove the duplicate parts of stdio.h from io.h. However, the removal of stdio.h from io.h did not put the duplicate parts from stdio.h back into io.h. If io.h had been correctly updated to include the now removed parts this wouldn't be an issue. There are other items that were removed from io.h besides the constants you mention for example rename and remove. > My Linux headers do have the `#ifndef' guard in unistd.h, but not in stdio.h; > since the definitions must be identical in both places, I don't really see > the need for the guard in either. > Unless some compiler is complaining. Do note that MinGW runtime headers are used in more than just our versions of GCC. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: techtonik <tec...@us...> - 2006-12-14 14:24:19
|
Hello, everybody I wonder if it would be possible to include ftello/fseeko in those headers somewhere? Seems like they are missing. -- --t. |
From: Earnie B. <ea...@us...> - 2006-12-14 15:05:55
|
Quoting techtonik <tec...@us...>: > Hello, everybody > > I wonder if it would be possible to include ftello/fseeko in those > headers somewhere? Seems like they are missing. > Missing because http://www.google.com/search?hl=en&q=ftello+site%3Amsdn.microsoft.com&btnG=Google+Search which is what we use to define our headers. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Keith M. <kei...@us...> - 2006-12-14 20:03:57
|
On Thursday 14 December 2006 13:12, Earnie Boyd wrote: > > Pulling in all of stdio.h, via io.h or otherwise, just to get three > > constant definitions required for unistd.h, does seem a bit like > > overkill. =A0The Linux headers do *physically* reproduce the three > > constants in question, in both unistd.h *and* stdio.h; perhaps that wou= ld > > also be the cleanest solution for our needs. > > I was trying to point out that stdio.h was removed from io.h but based > on comments in stdio.h someone made a decision to include stdio.h into > io.h and remove the duplicate parts of stdio.h from io.h. =A0However, the > removal of stdio.h from io.h did not put the duplicate parts from > stdio.h back into io.h. So, that step broke io.h, and also unistd.h. I'm not intentionally being belligerent here; I do agree that simply includ= ing=20 stdio.h where these duplicate definitions are required is a Q&D solution, b= ut=20 is it the best solution? Why pollute the namespace with all declarations=20 exposed in stdio.h, just to get a few which should be declared in some lean= er=20 header? > If io.h had been correctly updated to include=20 > the now removed parts this wouldn't be an issue. Agreed. > There are other items=20 > that were removed from io.h besides the constants you mention for > example rename and remove. MSDN and POSIX agree that these two should be prototyped in stdio.h; POSIX requires them *nowhere* else, so any POSIX conforming application usi= ng=20 them *should* `#include <stdio.h>'. POSIX doesn't have `io.h', but MSDN=20 requires that rename() and remove() also be protototyped there. We need to= =20 correct that for M$ compatability, but these two really should *not* be=20 exposed via unistd.h, (although doing so surely wouldn't be harmful). > > My Linux headers do have the `#ifndef' guard in unistd.h, but not in > > stdio.h; since the definitions must be identical in both places, I don't > > really see the need for the guard in either. > > Unless some compiler is complaining. =A0Do note that MinGW runtime > headers are used in more than just our versions of GCC. Wouldn't such a compiler be technically broken? AIUI, the compiler should= =20 complain about duplicate #defines, only if they are inconsistent. But=20 assuming such a compiler does use our headers, shouldn't we conditionalise= =20 duplicate defines in *every* header where they appear? There is no guarant= ee=20 that stdio.h will be parsed before unistd.h; if the duplicate defines are=20 conditionalised in unistd.h but not in stdio.h, and unistd.h is included=20 first, then the compiler will baulk at stdio.h. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-12-14 21:06:16
|
Quoting Keith Marshall <kei...@us...>: > On Thursday 14 December 2006 13:12, Earnie Boyd wrote: >> > Pulling in all of stdio.h, via io.h or otherwise, just to get three >> > constant definitions required for unistd.h, does seem a bit like >> > overkill. The Linux headers do *physically* reproduce the three >> > constants in question, in both unistd.h *and* stdio.h; perhaps that would >> > also be the cleanest solution for our needs. >> >> I was trying to point out that stdio.h was removed from io.h but based >> on comments in stdio.h someone made a decision to include stdio.h into >> io.h and remove the duplicate parts of stdio.h from io.h. However, the >> removal of stdio.h from io.h did not put the duplicate parts from >> stdio.h back into io.h. > > So, that step broke io.h, and also unistd.h. > Yes. > I'm not intentionally being belligerent here; I do agree that simply > including > stdio.h where these duplicate definitions are required is a Q&D solution, but > is it the best solution? Why pollute the namespace with all declarations > exposed in stdio.h, just to get a few which should be declared in some leaner > header? > >> If io.h had been correctly updated to include >> the now removed parts this wouldn't be an issue. > > Agreed. > >> There are other items >> that were removed from io.h besides the constants you mention for >> example rename and remove. > > MSDN and POSIX agree that these two should be prototyped in stdio.h; > POSIX requires them *nowhere* else, so any POSIX conforming application using > them *should* `#include <stdio.h>'. POSIX doesn't have `io.h', but MSDN > requires that rename() and remove() also be protototyped there. We need to > correct that for M$ compatability, but these two really should *not* be > exposed via unistd.h, (although doing so surely wouldn't be harmful). > Unistd.h isn't defined by MSDN at all. Our version was a porting aid and not intended to be POSIX compliant. Io.h was chosen to be included because it was a best fit for unistd.h. >> > My Linux headers do have the `#ifndef' guard in unistd.h, but not in >> > stdio.h; since the definitions must be identical in both places, I don't >> > really see the need for the guard in either. >> >> Unless some compiler is complaining. Do note that MinGW runtime >> headers are used in more than just our versions of GCC. > > Wouldn't such a compiler be technically broken? AIUI, the compiler should > complain about duplicate #defines, only if they are inconsistent. But > assuming such a compiler does use our headers, shouldn't we conditionalise > duplicate defines in *every* header where they appear? There is no guarantee > that stdio.h will be parsed before unistd.h; if the duplicate defines are > conditionalised in unistd.h but not in stdio.h, and unistd.h is included > first, then the compiler will baulk at stdio.h. > I understand what your saying and wondered why only one of the files you're checking had guards. Probably because the test program included them in that order and -Wall caused warnings in some version of the compiler being tested as a SWAG. Compiler technology is beyond my scope of knowledge but I tend to be overly cautious with guarding against potential warnings. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Toshiba Satellite P105-S6114 Notebook http://give-me-an-offer.com/offers/computers/laptop/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma |
From: Keith M. <kei...@us...> - 2006-12-17 14:25:50
|
On Thursday 14 December 2006 21:06, Earnie Boyd wrote: > >> There are other items > >> that were removed from io.h besides the constants you mention for > >> example rename and remove. > > > > MSDN and POSIX agree that these two should be prototyped in stdio.h; > > POSIX requires them *nowhere* else, so any POSIX conforming application > > using them *should* `#include <stdio.h>'. =A0POSIX doesn't have `io.h',= but > > MSDN requires that rename() and remove() also be protototyped there. = =A0We > > need to correct that for M$ compatability, but these two really should > > *not* be exposed via unistd.h, (although doing so surely wouldn't be > > harmful). > > Unistd.h isn't defined by MSDN at all. Yes, I did realise this, thanks. > Our version was a porting aid=20 > and not intended to be POSIX compliant. =A0Io.h was chosen to be included > because it was a best fit for unistd.h. unistd.h is very specifically a POSIX header; hence, I'd actually have been= =20 very surprised if MSDN did define it. Irrespective of the original intent = to=20 only provide it as a porting convenience, because of its POSIX specificity,= I=20 don't think it unreasonable to provide that convenience in a POSIX complian= t=20 manner. I'm not suggesting that this should extend to supporting features = of=20 POSIX which aren't well supported by M$, but those that are common to both,= =20 or that are easily supported, should be declared as required by POSIX. > >> > My Linux headers do have the `#ifndef' guard in unistd.h, but not in > >> > stdio.h; since the definitions must be identical in both places, I > >> > don't really see the need for the guard in either. > >> > >> Unless some compiler is complaining. =A0Do note that MinGW runtime > >> headers are used in more than just our versions of GCC. > > > > Wouldn't such a compiler be technically broken? =A0AIUI, the compiler > > should complain about duplicate #defines, only if they are inconsistent. > > =A0But assuming such a compiler does use our headers, shouldn't we > > conditionalise duplicate defines in *every* header where they appear? > > =A0There is no guarantee that stdio.h will be parsed before unistd.h; if > > the duplicate defines are conditionalised in unistd.h but not in stdio.= h, > > and unistd.h is included first, then the compiler will baulk at stdio.h. > > I understand what your saying and wondered why only one of the files > you're checking had guards. Actually, the MinGW headers *are* consistent in providing the guards; it's = in=20 the GNU headers for my Linux native compiler, that I've observed the=20 inconsistency. Obviously, this isn't our concern, (although I should,=20 perhaps, raise a glibc bug report); sorry for any confusion caused. > Probably because the test program included=20 > them in that order and -Wall caused warnings in some version of the > compiler being tested as a SWAG. =A0Compiler technology is beyond my > scope of knowledge but I tend to be overly cautious with guarding > against potential warnings. Ok. I'll take a look at io.h, and add back anything that's needed for corr= ect=20 unistd.h behaviour, and I'll conditionalise the duplicates just in case. =20 I've already added `SEEK_SET' and friends to a locally patched copy; I can= =20 also add back the missing `rename()' and `remove()' prototypes. Is there=20 anything else which comes to mind? =46WIW, I've also defined a simple autoconf macro, to test for the broken=20 unistd.h, and substitute a local replacement in my package build, if needed. Perhaps we should create a CVS module, where we can collect such things.=20 Alternatively, I guess I could just submit it to the public autoconf archiv= e;=20 the disadvantage I see in that is that, it could then be lost amongst a=20 multitude of stuff, which is unrelated to MinGW; OTOH, it could have an=20 advantage, in that package developers who traditionally focus on *nix=20 platforms only, might just be made more aware of MinGW porting issues. Any thoughts? Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-12-17 16:58:15
|
Quoting Keith Marshall <kei...@us...>: > > Ok. I'll take a look at io.h, and add back anything that's needed > for correct > unistd.h behaviour, and I'll conditionalise the duplicates just in case. > I've already added `SEEK_SET' and friends to a locally patched copy; I can > also add back the missing `rename()' and `remove()' prototypes. Is there > anything else which comes to mind? > I found those by looking at stdio.h comments. I'm not sure if anything else is missing. > FWIW, I've also defined a simple autoconf macro, to test for the broken > unistd.h, and substitute a local replacement in my package build, if needed. > Perhaps we should create a CVS module, where we can collect such things. > Alternatively, I guess I could just submit it to the public autoconf archive; You alternative was the first thought I had. > the disadvantage I see in that is that, it could then be lost amongst a > multitude of stuff, which is unrelated to MinGW; OTOH, it could have an > advantage, in that package developers who traditionally focus on *nix > platforms only, might just be made more aware of MinGW porting issues. Autoconf has been open to windows patches before including VC type so a MinGW patch shouldn't be too bothersome. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Keith M. <kei...@us...> - 2006-12-17 21:19:09
|
On Sunday 17 December 2006 16:58, Earnie Boyd wrote: > Quoting Keith Marshall <kei...@us...>: > > Ok. I'll take a look at io.h, and add back anything that's needed > > for correct > > unistd.h behaviour, and I'll conditionalise the duplicates just in case. > > I've already added `SEEK_SET' and friends to a locally patched copy; I > > can also add back the missing `rename()' and `remove()' prototypes. Is > > there anything else which comes to mind? > > I found those by looking at stdio.h comments. I'm not sure if anything > else is missing. I'll try to do likewise. If I miss anything, I guess it can always be added later; at least we won't be in any worse shape than at present. > > FWIW, I've also defined a simple autoconf macro, to test for the broken > > unistd.h, and substitute a local replacement in my package build, if > > needed. Perhaps we should create a CVS module, where we can collect such > > things. Alternatively, I guess I could just submit it to the public > > autoconf archive; > > You alternative was the first thought I had. So, let's do it then. Should it go on SF or on sourceware? Any preferences for module name, and location within the CVS tree? > > the disadvantage I see in that is that, it could then be lost amongst a > > multitude of stuff, which is unrelated to MinGW; OTOH, it could have an > > advantage, in that package developers who traditionally focus on *nix > > platforms only, might just be made more aware of MinGW porting issues. > > Autoconf has been open to windows patches before including VC type so a > MinGW patch shouldn't be too bothersome. I was thinking more of the independently maintained macro archive, on SF, rather than anything integral to autoconf itself. I'm inclined to favour our own MinGW/MSYS specific repository initially; perhaps there's mileage in offering it to this broader focused archive as well. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-12-17 22:04:53
|
Quoting Keith Marshall <kei...@us...>: > > I was thinking more of the independently maintained macro archive, on SF, > rather than anything integral to autoconf itself. I'm inclined to favour our > own MinGW/MSYS specific repository initially; perhaps there's mileage in > offering it to this broader focused archive as well. > Ok, just create a module directory in the MinGW space. Or maybe even as a sub-directory of msys. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |