«

Hi

I am trying to write a portable C program.

However I have this problem. I need to get the user to input a filename
to save the results. But if he shall input a filename not in the form 8.3
then this will not be portable to DOS.

My question is: as DOS is a common target for C, wouldn't it be better if
fopen() only allowed strings of length <11 and in the format 8.3 for
maximum compatability, and had an undefined behavior if it was given a
string in another format?

Thanks.

On 2010-05-10, john <> wrote:
> I am trying to write a portable C program.

Good luck with that!

> However I have this problem. I need to get the user to input a filename
> to save the results. But if he shall input a filename not in the form 8.3
> then this will not be portable to DOS.

That's fine.

> My question is: as DOS is a common target for C, wouldn't it be better if
> fopen() only allowed strings of length <11 and in the format 8.3 for
> maximum compatability, and had an undefined behavior if it was given a
> string in another format?

No, that would be stupid. There are other filesystems with other, different,
restrictions on what names may be.

The correct solution is that names are not expected to be portable, but the
behavior of fopen() is -- it will open the file or return a null pointer so
that you know it failed.

Consider how crippling it would be trying to use C if you could never open any
file with a name that was impermissible on any piece of hardware anywhere;
keep in mind that colons can be part of file names on some machines and not
others, some machines allow multiple dots in names, some distinguish case
and some don't... There are no names that are completely portable, but
fopen() isn't built around whether the specific name provided would work
everywhere, but whether a higher level description of its functionality is
available.

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

john a écrit :
> Hi
>
> I am trying to write a portable C program.
>
> However I have this problem. I need to get the user to input a filename
> to save the results. But if he shall input a filename not in the form 8.3
> then this will not be portable to DOS.
>
> My question is: as DOS is a common target for C, wouldn't it be better if
> fopen() only allowed strings of length <11 and in the format 8.3 for
> maximum compatability, and had an undefined behavior if it was given a
> string in another format?
>
> Thanks.

DOS is an obsolete system that is no longer maintained by the company
that created it.

Yes, there are maybe some users but I would like to know what data do
you have that says that DOS is a "common target for C".

So, you propose that all other systems destroy their file systems to
please some die hard DOS users?

So, I can't name a file with:

ApplicationCore.c

but I have to name it

APPLICAT.C

so that it collides with

ApplicationOutput.c

that ALSO will be truncated to APPLICAT.C

The fact that for you this is natural and a matter of course shows only
that you have never really left DOS.

IT IS OK. Stay in there. But PLEEEEZ do not come out of your hole with
proposals like this.

Thanks in advance for your understanding.

jacob

On 5/10/2010 4:36 PM, john wrote:
> Hi
>
> I am trying to write a portable C program.
>
> However I have this problem. I need to get the user to input a filename
> to save the results. But if he shall input a filename not in the form 8.3
> then this will not be portable to DOS.

Why is that a problem? If he runs your program on DOS and
supplies a file name DOS doesn't accept, fopen() will return NULL
and you'll say "Sorry: can't use that file name." On the other
hand, if he runs your program on Linux why should he be limited
to using only the names DOS would accept, and be walled off from
the names Linux can use? Also, if he runs your program on Linux
and provides CON.DAT as the file name, should Linux bend over
backwards to send the output to a console (some console, somewhere)?

*Your* name is non-portable; will you stop using it?

> My question is: as DOS is a common target for C, wouldn't it be better if
> fopen() only allowed strings of length<11 and in the format 8.3 for
> maximum compatability, and had an undefined behavior if it was given a
> string in another format?

No.

--
Eric Sosman
lid

On May 10, 3:36*pm, john <j...@nospam.com> wrote:
> Hi
>
> I am trying to write a portable C program.
>
> However I have this problem. I need to get the user to input a filename
> to save the results. But if he shall input a filename not in the form 8.3
> then this will not be portable to DOS.
>

Sure it will. If the user insists on entering a string that isn't a
valid DOS file name, then that's the *user's* problem, not your code's
(modulo properly escaping backslashes in the path name and other
sanity checks; i.e. if the user enters "\a\path\name.txt", you need to
change it into "\\a\\path\\name.txt"). All your code has to do is
pass the string to fopen() and check the result. If the user entered
a bad filename, fopen() should return NULL, and you can then prompt
the user to try again (or cancel the operation).

> My question is: as DOS is a common target for C, wouldn't it be better if
> fopen() only allowed strings of length <11 and in the format 8.3 for
> maximum compatability, and had an undefined behavior if it was given a
> string in another format?
>
> Thanks.

Tying C stdio functions to a specific and obsolete file naming
convention is *not* going to maximize portability. If anything, such
a requirement would only marginalize C on many other platforms; most
users (including programmers) aren't going to willingly use a less-
expressive naming convention if they don't have to, and most
programmers aren't going to be enthusiastic about having to map longer
filenames to the 8.3 format and back.

The C language *shouldn't* care about file naming conventions; all it
cares about is passing a string to the underlying file system and
getting a file handle back. It's up to the underlying system to
determing whether the string represents a valid file name or not, and
to return the appropriate value to fopen().

John Bode <> writes:
> On May 10, 3:36Â*pm, john <j...@nospam.com> wrote:
>> I am trying to write a portable C program.
>>
>> However I have this problem. I need to get the user to input a filename
>> to save the results. But if he shall input a filename not in the form 8.3
>> then this will not be portable to DOS.
>>
>
> Sure it will. If the user insists on entering a string that isn't a
> valid DOS file name, then that's the *user's* problem, not your code's
> (modulo properly escaping backslashes in the path name and other
> sanity checks; i.e. if the user enters "\a\path\name.txt", you need to
> change it into "\\a\\path\\name.txt"). All your code has to do is
> pass the string to fopen() and check the result. If the user entered
> a bad filename, fopen() should return NULL, and you can then prompt
> the user to try again (or cancel the operation).

No, you don't need to escape backslashes in user-entered strings.
Backslashes need to be doubled only in string literals and character
constants.

If you read a string with fgets() (and drop the terminating
'\n'), you can pass that string directly to fopen(). If you try
to double the backslashes first, fopen() will see a string with
doubled backslashes.

As for portability, there are contexts in which you might want to
limit file names to the least common denominator, which might be
the DOS-style 8.3 format. For example, if you're distributing data
files, avoiding longer names can make your files more portable to a
wider variety of systems. More realistically, making sure you don't
have distinct file names that differ in case can be beneficial for
files that might be ported from, say, Unix to Windows.

But restricting the behavior of fopen() itself is not the way
to do this. It would have the very small benefit of warning you
about file names that might not be portable, but the huge drawback
of making it impossible to deal with any such files even when you
don't care whether DOS can support them.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

john <j...@nospam.com> wrote:
> My question is: as DOS is a common target for C, wouldn't
> it be better if fopen() only allowed strings of length <11
> and in the format 8.3 for maximum compatability, and had
> an undefined behavior if it was given a string in another
> format?

No, for reasons cited elsethread.

In any case, DOS has long file name support since 1994.

% type CON > "this is a long file name.txt"
This is a sentance in a file with a very long name.
^Z

% type lfn.c
#include <stdio.h>

int main(int argc, char **argv)
{
if (argc)
while (argv++, --argc)
{
static char line[1024];
FILE *fi = fopen(*argv, "r");
if (!fi) continue;
while (fgets(line, sizeof line, fi))
fputs(line, stdout);
fclose(fi);
}
return 0;
}

% acc lfn.c -o lfn.exe

% lfn "this is a long file name.txt"
This is a sentance in a file with a very long name.

% dir /B *.txt
this is a long file name.txt

%

If you're C implementation can't handle that, then upgrade,
e.g. DJGPP.

--
Peter

Keith Thompson wrote:

[filenames and dos stuff snipped]

Keith,

I finally have a gcc install on windows that works almost like I want it
too, but I'm missing it on one detail.

What is that group where they talk about this?

ms-dos.win32.programmer ?? Nothing I try works, and similar looking
groups are abandoned.

I have no place for this forum's name in my head. I apologize for
interrupting the continuity of this thread.

To OP, the C standard says nothing about filenames, so you might want to
find this group as well.
--
Uno

On May 11, 12:40*am, Richard Heathfield <r...@see.sig.invalid> wrote:
> jacob navia wrote:
> > john a écrit :
> >> Hi
>
> >> I am trying to write a portable C program.
>
> >> However I have this problem. I need to get the user to input a
> >> filename to save the results. But if he shall input a filename not in
> >> the form 8.3 then this will not be portable to DOS.
>
> >> My question is: as DOS is a common target for C, wouldn't it be better
> >> if fopen() only allowed strings of length <11 and in the format 8.3
> >> for maximum compatability, and had an undefined behavior if it was
> >> given a string in another format?
>
> >> Thanks.
>
> > DOS is an obsolete system that is no longer maintained by the company
> > that created it.
>
> Nevertheless, it is still used by real companies for real commercial
> purposes. No doubt the number of installations of MS-DOS is decreasing
> over time, but it's still > 0. This is not an argument for bowing C's
> knee to DOS file formats, of course - that would be silly for the
> reasons Seebs has already pointed out - but it is most certainly an
> argument against knee-jerk "DOS is dead" responses. When a programmer,
> through no fault of his own, is forced by circumstance to maintain a
> system that uses an antiquated OS because of external constraints over
> which he has no control, it is no comfort to him to be told "use a
> proper OS, you fool" when that's precisely what he wants to do and
> precisely what he's prevented from doing in his particular situation.


FWIW, reading between the lines a bit, I kind of got the impression
that the OP was more interested in the many, many storage devices that
are formatted as non-LFN FAT, rather than DOS, per-se. As a practical
matter FAT (particularly in non-LFN form) does define what might be
considered a lowest common denominator data exchange medium.

Of course that doesn't change the fact that the way the volume and
directories are accessed will be different between systems. Or that
this is an issue outside the C standard.

Le 11/05/2010 07:40, Richard Heathfield a écrit :
> When you transfer a file between two OSen that use
> incompatible filename conventions, you will almost certainly use a
> utility program to do so, and no doubt the author of that program will
> have provided a way for the file to be renamed during the transfer.

In my experience moving files back and forth between OSes, the above is
wildly overoptimistic. Truth is, the author of the transfert program has
declared job done when transfer of "textfile.txt" and "database.bin"
appeared to work.

In particular, under MacOS (the operating system of the Macintosh before
OS X), a filename can contain any of 255 characters, including '/' '\\'
'*' '?' '\0' '"' '\n' (which is 13 rather than the usual 10), with the
exception of ':' reserved for what other OS do with '/' or '\\', and a
unique mapping of codes to accentuated characters, and a limit of 31
chars (less for directories in volumes that support that), and
case-insensitivity for A-Z a-z; that's leaving aside the "file version"
(some silly extension of the file name that never caught). Simply said
no transfer utility handles it properly. Further a file comprises its
data, an optional "ressource fork" (think mini-database alongside the
file), and a handfull of indispensible attributes, making the whole idea
of transfering such a file an accident going to happen.


François Grieu