File names / portability

[Seebs]

I think you are being deliberately obtuse here.

You keep saying this when people react to your posts in reasonably sane
ways.

I am proposing no such thing. What I am proposing is that passing a
string to fopen() that is not in 8.3 format should invoke an undefined
behavior (actually, implementation defined behavior would be even better).

You can't possibly be this stupid.

Hint: What do you think it is right now?

Why do you think it matters whether the name is 8.3 or not? What if we
made it implementation-defined how ALL names work, whether or not they
were in an 8.3 format?

Functions that open additional (nontemporary) files require a file
name, which is a string. The rules for composing valid file names are
implementation-defined. Whether the same file can be simultaneously
open multiple times is also implementation-defined.

Oh, look. It's *ALREADY* implementation-defined.

A Linux implementation would be free to choose to open any filename you
threw at it. A DOS implementation obviously couldn't do this in the
absence of a LFN support layer.

In other words, it's implementation-defined what names are valid. Yeah,
uhm, we already did that.

There is no reason for it to be undefined behavior to provide an invalid
file name; invalid file names cause fopen to return a null pointer, because
they can't be opened. There is a great deal of reason for ALL file names
to be implementation-defined behavior.

The essentially-irrelevant 8.3 file name convention is of no interest to
anyone anywhere anymore. You can't even find *cameras* that don't support
long file names, so far as I can tell.

-s

 

[Eric Sosman]

[...] What I am proposing is that passing a
string to fopen() that is not in 8.3 format should invoke an undefined
behavior (actually, implementation defined behavior would be even better).

And since the length, syntax, and significance of the first
fopen() argument is *today* implementation-defined, you propose
to change... well, what, exactly?

 

[Kenny McCormack]

I think you are being deliberately obtuse here.[/QUOTE]

Gee. Ya think?

Being deliberately obtuse - aka, intentionally misunderstanding what
people post - is the oldest CLC trick in the book. Employed widely and
well.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

 

[Moi]

Keith Thompson wrote:

I am proposing no such thing. What I am proposing is that passing a
string to fopen() that is not in 8.3 format should invoke an undefined
behavior (actually, implementation defined behavior would be even
better).

What exactly are you trying to avoid ?
*) a user entering a filename that is invalid on the current host ?
*) ... a filename that is invalid on some other host ?
*) ... that contains foul language ?
*) ... ... in some foreign language ?

HTH,
AvK

 

[robertwessel2]

The essentially-irrelevant 8.3 file name convention is of no interest to
anyone anywhere anymore.  You can't even find *cameras* that don't support
long file names, so far as I can tell.

Interesting. My experience is the other way - most embedded devices
supporting FAT don't support LFN. Basic FAT(12/16/32) is patent free,
adding LFN support gets you hassles from MS. Now cameras exist
towards the higher end of the embedded spectrum, so many might support
LFN, but most appear to create 8.3 compatible names by default.

 

[Seebs]

Interesting. My experience is the other way - most embedded devices
supporting FAT don't support LFN. Basic FAT(12/16/32) is patent free,
adding LFN support gets you hassles from MS. Now cameras exist
towards the higher end of the embedded spectrum, so many might support
LFN, but most appear to create 8.3 compatible names by default.

The gizmos I've used may *create* 8.3 compatible names by default, but they
seem to correctly display files with other names.

-s

 

[John Bode]

I think you are being deliberately obtuse here.

I am proposing no such thing. What I am proposing is that passing a
string to fopen() that is not in 8.3 format should invoke an undefined
behavior (actually, implementation defined behavior would be even better)..

Passing *any* string to fopen() already invokes implementation-defined
behavior:

7.19.3/8: Functions that open additional (nontemporary) files
require a file
name, which is a string. The rules for composing valid
file names
are implementation-defined. Whether the same file can be
simultaneously open multiple times is also implementation-
defined.

What sort of *non* implementation-defined behavior were you
envisioning for strings in 8.3 format?

A Linux implementation would be free to choose to open any filename you
threw at it. A DOS implementation obviously couldn't do this in the
absence of a LFN support layer.

At which point fopen() on DOS would return NULL, which is already a
well-defined behavior.

I mean, what other behavior *should* you expect from fopen() if you
give it a string that doesn't correspond to a valid file name?

 

[Phil Carmody]

You keep saying this when people react to your posts in reasonably sane
ways.


You can't possibly be this stupid.

Wait a sec - this is the same guy as the other silly suggestions?
I think he might be. I almost suspect troll...

Phil

 

[Phil Carmody]

I am afraid you are incorrect. ALL Windows systems since Windows NT
3.1 have been based on the NT kernel, not DOS. The last
Windows-over-DOS system was Windows 98SE.

I'm afraid you are incorrect. Many Windows systems since Windows NT
3.1 have been based on DOS, not NT, such as WWG 3.11, Win95, and Win98.
Given how your paragraph ends, this really should come as no surprise.

Phil