[M3devel] Pathname.Legal

[Mika Nystrom]

I think "/" works as a directory separator on Windows as well as "\",
doesn't it?  Are there other limitations?

Also, the Modula-3 style nit-picker in me would prefer 

   SET OF CHAR { FIRST(CHAR) .. LAST(CHAR) } 

(if that is what you really mean).

    Mika

Neels Janosch Hofmeyr writes:
>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>--------------enigEAE3E5403C2A4908483A8A10
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>
>There is a different implementation of Pathname (i.e. PathnameWin32.m3
>in cm3/m3-libs/libm3/src/os/WIN32) which uses \ separators.
>
>But this makes me look at the windows code: it has the same limitation!
>
>I guess I should also apply the fix there, right??
>it says:
>
>CONST Legal =3D SET OF CHAR {'\001' .. '\177'} - SET OF CHAR {DirSepChar,=
>
>':'};
>  (* *** This should be as permissive as any NT file system. *)
>
>(note: \177 is in octal and is 127 in decimal)
>
>Tony Hosking wrote:
>> What happens on Windows?  There path separators include \.
>>
>> On Oct 16, 2007, at 5:44 PM, Neels Janosch Hofmeyr wrote:
>>
>>>
>>> Rodney M. Bates wrote:
>>>> Since the language itself specifies that program variables of type
>>>> CHAR are in ISO Latin-1, not just ASCII, I think extending compilers,=
>
>>>> etc., to handle those characters makes complete sense, without even
>>>> needing to view it as support for unicode or differing locales.
>>>>
>>>> Do I understand correctly that Neels' patch extends just to ISO
>>>> Latin-1?
>>>
>>> Well, the fix allows more characters. It does in no way change datatyp=
>e
>>> bitwidth, any conversion or any other behavior at all. It's just an
>>> abort condition which is made more lenient, so that it allows all CHAR=
>
>>> characters in a Pathname.T (which is a TEXT). *If* CHAR represents ISO=
>
>>> Latin-1, then the fix extends the range of allowed characters to ISO
>>> Latin-1 only.
>>>
>>> Do you know more about this? I can only guess. Olaf Wagner guessed it'=
>s
>>> fine to submit the fix. I encountered no problems using it with large
>>> numbers of filenames.
>>> Can you think of anything that might be a problem when allowing all
>>> CHARs in a file name?
>>>
>>> Regards!
>>> Neels
>>>
>>> --=20
>>> Neels Janosch Hofmeyr
>>> Software Developer
>>>
>>> neels at elego.de
>>> Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc
>>>
>>> elego Software Solutions GmbH           http://www.elegosoft.com
>>> Gustav-Meyer-Allee 25, Geb=E4ude 12       HRB 77719
>>> 13355 Berlin, Germany                   Amtsgericht Charlottenburg
>>> Tel.: +49 30 23 45 86 96                Sitz der Gesellschaft: Berlin
>>> Fax:  +49 30 23 45 86 95                Gesch=E4ftsf=FChrer: Olaf Wagn=
>er
>>>
>>>
>>
>
>--=20
>Neels Janosch Hofmeyr
>Software Developer
>
>neels at elego.de
>Public Key: http://binarchy.net/neels/neels.hofmeyr.public.key.asc
>
>elego Software Solutions GmbH           http://www.elegosoft.com
>Gustav-Meyer-Allee 25, Geb=E4ude 12       HRB 77719
>13355 Berlin, Germany                   Amtsgericht Charlottenburg
>Tel.: +49 30 23 45 86 96                Sitz der Gesellschaft: Berlin
>Fax:  +49 30 23 45 86 95                Gesch=E4ftsf=FChrer: Olaf Wagner
>
>
>
>--------------enigEAE3E5403C2A4908483A8A10
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: OpenPGP digital signature
>Content-Disposition: attachment; filename="signature.asc"
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.6 (GNU/Linux)
>
>iD8DBQFHFT0jRpHEG7B8Y+ARAlQeAKDJwIVJngSDSZy0HTvZKVXYg0PMPQCgo+Gn
>3oY6Q1ZK45iODSSURAcCpiI=
>=VXmb
>-----END PGP SIGNATURE-----
>
>--------------enigEAE3E5403C2A4908483A8A10--