On Sat, 25 Jan 2014 12:12:55 -0500, Peter Relson wrote:

>Further clarification:
>
>Today: If IEASYMxx tries to create a symbol with its value being "too
>long", it is rejected.
>Tomorrow: That same definition would be rejected similarly.
>
>There would be a way to indicate "I am creating this symbol and I
>explicitly want you to let me provide a longer value than the name".
>Likely that way would be by allowing a character in the symbol name that
>is not currently allowed, and thus use of that symbol would be an overt,
>and visual, indication of the new function. For such a symbol, there would
>still be a maximum but it would not be the length of the symbol name.
>
Hypothetically, this would introduce the possibility of a new error mode:
buffer overflow.  I would hope that I would hope that such an error
would be reported in the completion status of the hypothetical
symbol resolution facility.


On Sat, 25 Jan 2014 18:30:01 -0500, Shmuel Metz (Seymour J.)  wrote:
>
>>The reality is that the choices lie between
>>- changing nothing and ... to give them
>>the "rope" and  leave it to them to avoid doing something that
>>"hurts".
>
>That's a false dichotomy. The actual choice lies among
>
> - Changing nothing
> - Changing the behavior of the existing interface
> - Adding a new interface while retaining the old one.
> 
Well said, Shmuel.  Of course if the implementation followed
Peter's hypothetical technique a new interface would be required.
Suppose the hypothetical distinguishing character is '_', not
currently allowed in symbol names.  So a programmer might
have in his code "&FOO_BAR".  Today the '_' terminates the
symbol.  With the hypothetical change, the symbol would be
recognized not as "&FOO", but as "&FOO_BAR", which might
have a different value, or be undefined.  In order to avoid the
need to inspect "thousands or millions of lines of code" in
order to change every existing occurrence of "&FOO_" to 
&FOO._" the new interface is needed.  The collateral benefit
is that such a hypothetical new interface could have a mechanism
for reporting errors such as buffer overflow.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to