Assigning values to a struct

[Alf P. Steinbach]

* Victor Bazarov:

<OT>
You seem to imply that "recent" Windows (as opposed to "early") are
somehow case-sensitive. That's incorrect. .C and .c are the same
on _all_ MS Windows file systems. They do keep the "correct" case
(the case with which the file was originally named) and can display
it if asked, but the case is not considered when finding/opening
a file by name.
</OT>

Uh, I hate to correct an off-topic correction, but the 32-bit Windows
file system, NTFS, has always supported case sensitive file names. It
also supports hard links, internal file streams, very long file names
(cirka 2^15 chars, which the standard Windows shell can't handle...),
and in Windows Vista the brilliant technicians at Microsoft even
introduced symbolic links like Unix has had since the 1970's![1]

Tools are a different matter.

Most Windows tools treat file names as not case sensitive, and as being
limited to a few hundre characters, because that's the usual Windows
/convention/ and the default behavior (sorry, I don't know what that
means exactly for characters with one-to-many upper/lower-case).

Cheers, & hth.,

- Alf

Follow-ups set to [comp.os.ms-windows.programmer.win32].


[1] I don't know exactly when Unix got symbolic links, but surely it
could not have been as late as the 1980's. Correct me if wrong.

 

[Jerry Coffin]

[ ... ]

You seem to imply that "recent" Windows (as opposed to "early") are
somehow case-sensitive. That's incorrect. .C and .c are the same
on _all_ MS Windows file systems. They do keep the "correct" case
(the case with which the file was originally named) and can display
it if asked, but the case is not considered when finding/opening
a file by name.

This correctly describes the default behavior of Windows, but not all of
the behavior. In particular, the Windows CreateFile call supports a
FILE_FLAG_POSIX_SEMANTICS, which makes it treat the file name in a case
sensitive manner.

When opening a file with portable code, there's no way to affect that
flag, so you're entirely at the whim of the library implementation -- it
could be case sensitive or case insensitive. With proper documentation,
I'm pretty sure it could even do something silly like being case
sensitive during odd seconds and case insensitive during even seconds...

 

[Victor Bazarov]

[ ... ]

You seem to imply that "recent" Windows (as opposed to "early") are
somehow case-sensitive. That's incorrect. .C and .c are the same
on _all_ MS Windows file systems. They do keep the "correct" case
(the case with which the file was originally named) and can display
it if asked, but the case is not considered when finding/opening
a file by name.

This correctly describes the default behavior of Windows, but not all
of the behavior. In particular, the Windows CreateFile call supports a
FILE_FLAG_POSIX_SEMANTICS, which makes it treat the file name in a
case sensitive manner.

When opening a file with portable code, there's no way to affect that
flag, so you're entirely at the whim of the library implementation --
it could be case sensitive or case insensitive. With proper
documentation, I'm pretty sure it could even do something silly like
being case sensitive during odd seconds and case insensitive during
even seconds...

Well, you're probably right (I've never used that flag with CreateFile)
but the essence is that using Standard C++ means of opening a file,
there is no way to distinguish between .c and .C file extension on MS
Windows, which is what most likely happens with a C++ compiler or its
preprocessor.

V

 

[Jerry Coffin]

[ ... ]

Well, you're probably right (I've never used that flag with CreateFile)
but the essence is that using Standard C++ means of opening a file,
there is no way to distinguish between .c and .C file extension on MS
Windows, which is what most likely happens with a C++ compiler or its
preprocessor.

The point is that it can if it wants to. Most compilers for Windows
observe the local custom (so to speak) and ignore case -- but the system
allows them to be case sensitive if they choose to do so.