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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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_IFBLK ) /* 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 discrete value, so declaring it as a possible combination of other equally discrete 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.
Last edit: Keith Marshall 2016-05-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Thinking about it retrospectively, 0x3000 actually isn't a very clever choice for _S_IFBLK, because evaluation of _S_ISBLK(mode), in the event that mode actually does somehow assume a value equivalent to _S_IFBLK, would boil down to
(0x3000 & 0xF000) == 0x3000
which is of course true, whereas we believe _S_ISBLK should always evaluate as false, (because the underlying _S_IFBLK indication is unsupported). To guarantee this, _S_IFBLK should include at least one bit which is always filtered out by the 0xF000 mask ... 0x3001 would suffice; thus _S_ISBLK could evaluate as
(0x3001 & 0xF000) == 0x3001
which is guaranteed to evaluate as false.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> [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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 <dannysmith@users.sourceforge.net>
* 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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Commenting out/deleting all the _S_IFBLK stuff
> may surprise some people.
Maybe, but which is the better option?
1) Let the compiler issue a (terse form of the) message:
"Hey, it may surprise you to learn that this usage of S_IFBLK isn't supported on MS-Windows; maybe you should consider the implications of that, in the context of your application".
2) Just assume that it's ok to pretend that S_IFBLK is ok, and it's ok to never match the condition it tests; leave the user in blissful ignorance, until he finds out the hard way, at runtime, that his code isn't working as he expects.
I know which of these I would prefer; it certainly isn't the latter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I need to review to find if we still have an issue.
We do, but it's easily remedied. I propose closing, after applying the attached patch, which:
Declines to define _S_IFBLK, or any of its derivatives, unless the user kludges it by defining _MINGW_SYS_STAT_EXTENDED, (which I propose to leave undocumented, beyond its casual appearance here).
Substitutes a new arbitrary value for _S_IFBLK, if the user does kludge it, such that S_ISBLK and _S_ISBLK are guaranteed to evaluate as false.
patch to fix it
Logged In: YES
user_id=15438
Originator: NO
Why should I take your word for it. Where is the proof?
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)...
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
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.
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.
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?
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.
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.
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.
Logged In: YES
user_id=823908
Originator: NO
Very likely, but...
0x1000 == S_IFIFOand0x2000 == S_IFCHR, and normal usage would be something like: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_modefield isn't formed as a logical OR of any other classification bits; it's a discrete value, so declaring it as a possible combination of other equally discrete values seems confusing, if not just plain wrong.as can I.
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.At the very least, we should have a more explicit comment in stat.h, to the effect that
S_IFBLKis defined purely as a portability hook for POSIX code, and, since MS stat() has no concept ofS_IFBLK, the value of 0x3000 has been chosen because it can be guaranteed that it will never be returned in thest_modefield. 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.Last edit: Keith Marshall 2016-05-18
Thinking about it retrospectively,
0x3000actually isn't a very clever choice for_S_IFBLK, because evaluation of_S_ISBLK(mode), in the event thatmodeactually does somehow assume a value equivalent to_S_IFBLK, would boil down towhich is of course true, whereas we believe
_S_ISBLKshould always evaluate as false, (because the underlying_S_IFBLKindication is unsupported). To guarantee this,_S_IFBLKshould include at least one bit which is always filtered out by the0xF000mask ...0x3001would suffice; thus_S_ISBLKcould evaluate aswhich is guaranteed to evaluate as false.
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
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.
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.
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 <dannysmith@users.sourceforge.net>
* 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
Logged In: YES
user_id=823908
Originator: NO
> Commenting out/deleting all the _S_IFBLK stuff
> may surprise some people.
Maybe, but which is the better option?
1) Let the compiler issue a (terse form of the) message:
"Hey, it may surprise you to learn that this usage of S_IFBLK isn't supported on MS-Windows; maybe you should consider the implications of that, in the context of your application".
2) Just assume that it's ok to pretend that S_IFBLK is ok, and it's ok to never match the condition it tests; leave the user in blissful ignorance, until he finds out the hard way, at runtime, that his code isn't working as he expects.
I know which of these I would prefer; it certainly isn't the latter.
There isn't an end to this story. I need to review to find if we still have an issue.
We do, but it's easily remedied. I propose closing, after applying the attached patch, which:
_S_IFBLK, or any of its derivatives, unless the user kludges it by defining_MINGW_SYS_STAT_EXTENDED, (which I propose to leave undocumented, beyond its casual appearance here)._S_IFBLK, if the user does kludge it, such thatS_ISBLKand_S_ISBLKare guaranteed to evaluate as false.