Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000573 [1003.1(2008)/Issue 7] Base Definitions and Headers Comment Enhancement Request 2012-05-31 16:41 2022-06-09 15:33
Reporter joerg View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Closed  
Name Jörg Schilling
User Reference
Section 3.276
Page Number 77
Line Number 2198
Interp Status ---
Final Accepted Text
Summary 0000573: Please add '+' to the portable filename character set
Description It seems that the plus sing was not in the portable filename character set, because DOS 8.3 names did not allow it. Today, filesystems are less picky with filenames and it would help to add characters, in special as other definitions
in the standard are derived from the portable filename character set.

This request is related to issue #373.
Desired Action Add + to the list of valid characters
Tags No tags attached.
Attached Files

- Relationships
related to 0000373Closedajosey make should allow dash in macro names 
related to 0000251Closedajosey Forbid newline, or even bytes 1 through 31 (inclusive), in filenames 

-  Notes
eblake (manager)
2012-06-14 15:31

Part of this proposal should be considering the inclusion of a new option to pathchk; -p should always target the current standard (so for Issue 7, -p rejects '+', but for Issue 8, -p would allow '+'; similar for a leading '+' with -P), a new option would make it possible even for an Issue 8 pathchk to validate whether the name complies with Issue 7.
psmith (developer)
2012-06-14 17:35

One issue that needs to be addressed is how variable names ENDING with special characters will interact with assignment operators that may begin with special characters. For example "+" is perfectly valid in variables in GNU make today, however if you write "C++=g++" this is interpreted to be "C+ += g++", not "C++ = g++", because "+=" is a valid assignment operator.

There may be more special operators defined by other versions of make and I don't want to restrict this even for GNU make. Perhaps we need to add a requirement that either variables must end with a alphanumeric character or there must be whitespace between the variable and the assignment operator. Or something like that.
joerg (reporter)
2012-06-16 13:14
edited on: 2012-06-16 13:15

Other make implementations require one or more space characters before "+=". I was not even awave of that gmake seems to behave this way.

For this reason, all portable make files have white space before the "+=".

If someone for some reason would like to implement "-=" as operator, he would also need to require a space before this new operator.

I have no idea from which make implementation gmake copied this feature, but SunPro make introduced it in spring 1986 and since then has the following content in the manual page:

     += When used in place of =, appends a string to a
              macro definition (must be surrounded by white
              space, unlike =).

psmith (developer)
2012-06-18 19:30

It doesn't matter to me which make had what first or whether features were copied or co-invented. I am requesting that any new wording in the standard allowing new characters in variable names should be clear about what happens in situations where this creates ambiguities with assignment operators, and that it does not invalidate GNU make's current behavior as being non-compliant.
joerg (reporter)
2012-06-21 11:59

The following locations contain the term portable filename character set:

1856 3.189 Group name
2189 3.275 Portable character set
2196 3.266 Portable filename charcter set
2911 4.7 filename portability
4072 charclass
42412 mkdtmp()
80991 chown()
94296 m4/mkstemp
98969 pathchk
99287 pax
109681 uucp
109918 uudecode
110234 uux
115106 Rationale for base definitions
115626 A.4.7 Filename Portability
111600 Environment/LOGNAME
shware_systems (reporter)
2013-08-02 22:30

> It seems that the plus sign was not in the portable filename character set, because DOS 8.3 names did not allow it. Today, filesystems are less picky with filenames and it would help to add characters, in special as other definitions in the standard are derived from the portable filename character set.

> This request is related to issue #373.

One issue, though more systems are tolerant of them, the current EFI BIOS versions many hardware implementations are based upon uses FAT32 as its native file system, which still has the 8.3 restrictions, so any implementation built for those machines will have to take into account the possibility that the restriction holds if the partition for the BIOS gets mounted. I'd like to see this too, but on that basis I recommend rejecting it - at least until EFI switches to something like ISO-9660 (CD-ROM) for its boot partition format.
shware_systems (reporter)
2013-08-02 22:58

As to the issue of whether punctuation besides "_" should be allowed in environment or shell variable identifiers, I'd be more open to defining an operator like "v'" & "V'" (for wide chars), like C's "L'", to be used when such names would have to be created or disambiguated from other punctuation as operators.
It could even use the '' convention to include single quotes inside those names as apostrophes.
This would be for Version 8, though, as a Future Direction for shell and make, and similar utilities.
I don't believe it would break any existing scripts.
shware_systems (reporter)
2013-08-11 15:24

Also, the relation to #373, I looked at the code for gmake. It permits dashes
as first characters and internal characters, but only when the macro definition
is not at first position of the command line. Then it strips it off as an
operator like POSIX make, so --Var-name = would be needed, not just -Var-name =.
It also makes special checks that for the [macro=value...] command line option
only var names that start with letter or _, and letter,_,digit following up to
= to stay exported. Variables with +,., or - are "local only". So while .,+,-
are a permitted extension, it's restricted use and POSIX macro names didn't
list any restrictions defined as is, that I saw. Not allowing '-' as a leading
char is a safety feature too, in that within a makefile they're used directly
so can be easy enough to forget that the dereference $() or ${} is needed when
using them as shell or app invocation parameters. So, if they are to be added
I believe the best compromise is that initial char will be letter or '_';
internal chars may be letter, digit, punct that isn't going to be confused as
operators, shell operators, or invocation switches incompatible with getopt()
in that parse position, such as '-' and '_', but not '='; and end with letter,
digit or '_'. A list of which chars are known to create conflicts, like '=',
would be useful, perhaps. Verbiage such as: "If a char of class punct other
than '_' is used in a macro name, it is recommended that a SP char precede any
operators for maximum portability, as differences of interpretation by
implementation-specific parsing conventions may not recognize intended end of
name otherwise."

I believe gmake does a one-char lookahead if a possible operator detected, which
could be why C++= parses as C+ +=, not 'longest-match' parsing as expected of
BREs and EREs that would produce C++ =. [-v('|")macro=data('|")...] and -V('|")
are available as command line options, for special char macro names that should
be exported, presuming all chars in definition are accepted by put/setenv().
The explicit switch and quoting required I think makes it compatible with everything that isn't using a -v or -V switch now.
dannyniu (reporter)
2016-02-18 04:23

I agree with note 0001695, but for some different reasons.

The '+' the plus sign is a special character in URLs, which means it'll have to be represented differently from itself in order to represent itself.

Also I think 'portable' in this case means both forward and backward compatibility, it means greatest common divisor, so newer versions' PFCS == older versions' PFCS (PFCS = portable filename character set).
geoffclare (manager)
2022-06-09 15:33

This was discussed in the June 9th, 2022 teleconference. In view of the potential problems that adding '+' might cause, as raised in earlier bug notes, it was decided that this bug should be rejected.

- Issue History
Date Modified Username Field Change
2012-05-31 16:41 joerg New Issue
2012-05-31 16:41 joerg Status New => Under Review
2012-05-31 16:41 joerg Assigned To => ajosey
2012-05-31 16:41 joerg Name => Jörg Schilling
2012-05-31 16:41 joerg Section => 3.276
2012-05-31 16:41 joerg Page Number => 77
2012-05-31 16:41 joerg Line Number => 2198
2012-06-01 10:07 geoffclare Project 2008-TC1 => 1003.1(2008)/Issue 7
2012-06-14 15:20 eblake Relationship added related to 0000373
2012-06-14 15:31 eblake Note Added: 0001256
2012-06-14 17:35 psmith Note Added: 0001259
2012-06-16 13:14 joerg Note Added: 0001264
2012-06-16 13:15 joerg Note Edited: 0001264
2012-06-18 19:30 psmith Note Added: 0001267
2012-06-21 11:59 joerg Note Added: 0001268
2012-08-03 19:36 eblake Relationship added related to 0000251
2012-08-03 22:37 eadler Issue Monitored: eadler
2013-08-02 22:30 shware_systems Note Added: 0001695
2013-08-02 22:58 shware_systems Note Added: 0001696
2013-08-02 22:59 shware_systems Issue Monitored: shware_systems
2013-08-11 15:24 shware_systems Note Added: 0001710
2016-02-18 04:23 dannyniu Note Added: 0003077
2022-06-09 15:33 geoffclare Interp Status => ---
2022-06-09 15:33 geoffclare Note Added: 0005847
2022-06-09 15:33 geoffclare Status Under Review => Closed
2022-06-09 15:33 geoffclare Resolution Open => Rejected

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker