From: SourceForge.net <no...@so...> - 2008-04-24 23:50:29
|
Bugs item #1942809, was opened at 2008-04-15 20:44 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1942809&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: Known bugs Status: Closed Resolution: Remind Priority: 5 Private: No Submitted By: Andreas Betz (qwert667) Assigned to: Nobody/Anonymous (nobody) Summary: wrong value for S_IFBLK in sys/stat.h Initial Comment: The value defined for _S_IFBLK in sys/stat.h is wrong. It should be 0x6000 (060000) instead of 0x3000. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2008-04-25 11:50 Message: Logged In: YES user_id=11494 Originator: NO > It's not broken. What I am concerned about is that the current _S_IFBLK value has been unchanged since at least 1999. I think I may have added the comment about it when I did this: 2001-10-30 Danny Smith <dan...@us...> * include/sys/stat.h: Make S_IS* macros safer. Before then the S_IS* macros were of the form # define S_ISFIFO(m) ((m) & S_IFIFO) and indeed there was a bug. Commenting out/deleting all the _S_IFBLK stuff may surprise some people. Perhaps not. Unfortunately, we won't know until a release since very few people test CVS. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-04-25 09:53 Message: Logged In: YES user_id=823908 Originator: NO > [my original comment] > would be valid if we could assume that each of the S_IFOO > modes had it own bit. That assumption is not supported by > POSIX standard. We test a FIFO by > > # define S_ISFIFO(m) (((m) & S_IFMT) == S_IFIFO) > > _not_ by > # define S_ISFIFO(m) ((m) & S_IFIFO) > > So current S_ISBLK does not really require "a block special > device to be simultaneously a FIFO *and* a character special > device" Exactly. I didn't indend to imply any such thing; rather I was trying to explain, as you are, that the assumption that 0x3000 may have been chosen for S_IFBLK because that is the logical OR of S_IFIFO and S_IFCHR doesn't make a lot of sense. > AFAICT, S_ISBLK is always false on MS Windows > whether we define it to be 0x6000 or 0x3000. Yes, if stat() is guaranteed to never return either of these values in the appropriate bitfield of st_mode, that would be so, and yes, you may argue that... > It's not broken. However, MSW doesn't actually have any concept of S_IFBLK or S_ISBLK, in terms of what is supported by stat(). As a porter of POSIX code, I would much rather have the compiler tell me that my code makes use of an unsupported feature, than have it arbitrarily and silently insert code which pretends that the feature is supported, and then maybe does something unexpected at run time, even if that is to only return false, where I might be looking for true. Forewarned is forearmed, so in this sense, I *would* class it as broken. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2008-04-24 22:38 Message: Logged In: YES user_id=11494 Originator: NO This comment: <quote> "Very likely, but... > and 0x3000 ORs with 0x1000 and 0x2000. 0x1000 == S_IFIFO and 0x2000 == S_IFCHR, and normal usage would be something like: if( (status.st_mode & S_IFMT) == S_IBLK ) /* it's a block special device */ so requiring a block special device to be simultaneously a FIFO *and* a character special device, which isn't just anomalous; it's surely impossible, for the three classes would seem to be mutually exclusive. In fact, the value assigned in the st_mode field isn't formed as a logical OR of any other classification bits; it's a discreet value, so declaring it as a possible combination of other equally discreet values seems confusing, if not just plain wrong." </quote> would be valid if we could assume that each of the S_IFOO modes had it own bit. That assumption is not supported by POSIX standard. We test a FIFO by # define S_ISFIFO(m) (((m) & S_IFMT) == S_IFIFO) _not_ by # define S_ISFIFO(m) ((m) & S_IFIFO) So current S_ISBLK does not really require "a block special device to be simultaneously a FIFO *and* a character special device" AFAICT, S_ISBLK is always false on MS Windows whether we define it to be 0x6000 or 0x3000. It's not broken. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-04-22 04:34 Message: Logged In: YES user_id=15438 Originator: NO I found one occurrence of S_IFBLK at microsoft.com[1] in a POSIX code sample discussing RAW I/O. <quote name="Keith Marshall"> "However, since this is a porting issue, it may be better to force the repercussions of removal, and so force POSIX code porters to at least consider the issue, and provide an appropriate fall back specific to the application in question -- maybe it isn't acceptable to be unable to identify a block special device, and not to be advised of the limitation." </quote> I agree with this and we should make sure the porters are aware of the MicroSoft technet documentation for porting POSIX to Windows. [1] http://technet.microsoft.com/en-us/library/bb497011.aspx ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-04-22 03:26 Message: Logged In: YES user_id=823908 Originator: NO > I suspect that it _S_IFBLK is defined as a porting helper Very likely, but... > and 0x3000 ORs with 0x1000 and 0x2000. 0x1000 == S_IFIFO and 0x2000 == S_IFCHR, and normal usage would be something like: if( (status.st_mode & S_IFMT) == S_IBLK ) /* it's a block special device */ so requiring a block special device to be simultaneously a FIFO *and* a character special device, which isn't just anomalous; it's surely impossible, for the three classes would seem to be mutually exclusive. In fact, the value assigned in the st_mode field isn't formed as a logical OR of any other classification bits; it's a discreet value, so declaring it as a possible combination of other equally discreet values seems confusing, if not just plain wrong. > I can support a patch to remove it ... as can I. > but I fear some repercussions from the removal. There may be merit in retaining it as a portability hook, as long as it has a value which can be guaranteed never to be returned under any other circumstances; maybe 0x3000 is such a value, since MS stat appears to have no concept of a block special device, (or at least no concept of S_IFBLK), but it certainly can't be both a FIFO and a character special device. > I'll mark this a closed and will expect you to provide the patch > to remove it committed to the patch tracker with this bug issue > mentioned in the comments. At the very least, we should have a more explicit comment in stat.h, to the effect that S_IFBLK is defined purely as a portability hook for POSIX code, and, since MS stat() has no concept of S_IFBLK, the value of 0x3000 has been chosen because it can be guaranteed that it will never be returned in the st_mode field. However, since this is a porting issue, it may be better to force the repercussions of removal, and so force POSIX code porters to at least consider the issue, and provide an appropriate fall back specific to the application in question -- maybe it isn't acceptable to be unable to identify a block special device, and not to be advised of the limitation. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-04-22 02:12 Message: Logged In: YES user_id=15438 Originator: NO I don't know where 0x3000 came from either. I suspect that it _S_IFBLK is defined as a porting helper and 0x3000 ORs with 0x1000 and 0x2000. I can support a patch to remove it but I fear some repercussions from the removal. I'll mark this a closed and will expect you to provide the patch to remove it committed to the patch tracker with this bug issue mentioned in the comments. ---------------------------------------------------------------------- Comment By: Andreas Betz (qwert667) Date: 2008-04-20 13:49 Message: Logged In: YES user_id=2063443 Originator: YES No, I don't want that! I agree with you! According to msdn, there is no S_IFBLK for Win, so it also shouldn't be in mingw. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-04-20 09:07 Message: Logged In: YES user_id=823908 Originator: NO So, you want MinGW's S_IFBLK to match the appropriate value for Linux's glibc? That's *wrong* in every possible way; it must match what is appropriate for Win32's MSVCRT.DLL, if indeed anything is. In fact, Windows doesn't appear to support any feature which is analogous to S_IFBLK, so the value of 0x3000 certainly does appear suspect; I don't know where that value came from, but if it is to be defined at all, then *zero* would seem to be a more appropriate value. ---------------------------------------------------------------------- Comment By: Andreas Betz (qwert667) Date: 2008-04-18 22:13 Message: Logged In: YES user_id=2063443 Originator: YES Seems like MS doesn't define _S_IFBLK at all: http://msdn2.microsoft.com/en-us/library/aa273367(VS.60).aspx That's what all MS sys/stat.h files i could find said, too. For file types just 0x1000 (pipe), 0x2000 (character special), 0x4000 (directory) and 0x8000 (regular) are defined. Where does that 0x3000 in mingw's sys/stat.h come from? ---------------------------------------------------------------------- Comment By: Andreas Betz (qwert667) Date: 2008-04-16 09:41 Message: Logged In: YES user_id=2063443 Originator: YES OK, sorry, didn't know that. I just hit that bug/problem/whatever at work and wanted to quickly inform the developers about it. Since I didn't need any help - my patch works good for me - I thought this would be the right way. Actually I've got no idea if this value is ever used in Win. I just use it to build archives containing device nodes for Linux and for this case the value really is wrong (proven by mentioned documentation). I've got hardly any time to do anything more about it at the moment, so feel free to close this report again. ---------------------------------------------------------------------- Comment By: Andreas Betz (qwert667) Date: 2008-04-16 09:13 Message: Logged In: YES user_id=2063443 Originator: YES OK, sorry, didn't know that. I just hit that bug/problem/whatever at work and wanted to quickly inform the developers about it. Since I didn't need any help - my patch works good for me - I thought this would be the right way. Actually I've got no idea if this value is ever used in Win. I just use it to build archives containing device nodes for Linux and for this case the value really is wrong (proven by mentioned documentation). I've got hardly any time to do anything more about it at the moment, so feel free to close this report again. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-04-16 07:04 Message: Logged In: YES user_id=15438 Originator: NO Please review the proper techniques for submitting bugs. Looking at other header source files isn't proper. MicroSoft doesn't provide man pages. They provide what they call the MSDN. You're the one stating the bug; you're the one responsible to provide the proof. http://www.mingw.org/MinGWiki/index.php/FAQ http://www.mingw.org/MinGWiki/index.php/ReportBugs ---------------------------------------------------------------------- Comment By: Andreas Betz (qwert667) Date: 2008-04-16 05:36 Message: Logged In: YES user_id=2063443 Originator: YES Just take a look into any other stat.h or in to the manpage of stat(2)... ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-04-15 23:23 Message: Logged In: YES user_id=15438 Originator: NO Why should I take your word for it. Where is the proof? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1942809&group_id=2435 |