«

On 2010-05-13, john <> wrote:
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 5/13/2010 2:18 PM, john wrote:
>
> [...] 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?

--
Eric Sosman
lid

In article <hshfq6$vh$>, john <> wrote:
....
>I think you are being deliberately obtuse here.

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...

On Thu, 13 May 2010 18:18:46 +0000, john wrote:

> Keith Thompson wrote:

>>
>> The syntax of the file name string passed to fopen() is determined
>> entirely by the underlying operating system. (Well, the C
>> implementation could play some games with it, but I know of none that
>> do so.)
>>

>
> 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

On May 13, 2:24*pm, Seebs <usenet-nos...@seebs.net> wrote:
> 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.

On 2010-05-13, <> wrote:
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On May 13, 1:18*pm, john <j...@nospam.com> wrote:
> Keith Thompson wrote:
> > If you want to give your files short names, that's fine. *But I really
> > hope you're not still seriously suggesting that C implementations should
> > be unable to open files with longer names.
>
> > And what about systems with even more restrictive file names that DOS?
> > What about path names?
>
> > The syntax of the file name string passed to fopen() is determined
> > entirely by the underlying operating system. *(Well, the C
> > implementation could play some games with it, but I know of none that do
> > so.)
>
> > Suppose I want my C program, running on a Linux system, to open a file
> > called "longfilename.foobar.data". *You're proposing that it should be
> > unable to do so.
>
> > No.
>
> 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?

Seebs <usenet-> writes:
> On 2010-05-13, john <> wrote:
>> 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.

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

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

Geoff <> writes:
> On Wed, 12 May 2010 22:49:41 +0000 (UTC), john <>
> wrote:
>
>>Most Linux distributions come with the DOSBox emulator. And Windows
>>(except Windows NT) is still built on DOS: just select Run from the start
>>menu and type command.com! Also autoexec.bat and config.sys are still
>>there from DOS.
>
> 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
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1