From: Scott Klement
If you changed the spec to look like this:
D myVar s 500A varying(*max64kb)
Then it'd be rather unclear when I said that 500 was the maximum number
of characters. It's hard to explain why both 500 and 64k are the
maximum in the same statement.
This is an interesting point. You COULD theoretically determine the pointer
size based on the maximum defined length of the field. Which brings us to
an even trickier question: how would you define a field with a length of of
128TB anyway? The actual length is 140737488355328, and I'm pretty
confident that you can't define that on a D spec. With only seven positions
for length, you're limited to about 8MB.
Maybe an "allocation units" keyword?
D myVar s 256A allocunit(*MB)
Not only that, but it's quite a bit of
typing to type Varying(*max128tb) (or any of the *MAX things).
Well, I'm not worried about typing. Having values that are readable makes
sense; let your IDE do your typing for you. Either you're faster than the
IDE (at which point typing doesn't matter) or you're not and you let the IDE
do the work. Your other point aside, I'd opt for readability over brevity,
especially since this is something you're unlikely to use a whole bunch.
Please, lets not make things more complicated to teach then they already
are.
The only issue is people who have already hardcoded -2 and +2 a lot; you've
said yourself that you're one of those. Here's a possible scenario:
IBM could just size the pointer based on the defined size of the field,
which would currently leave all code backwards compatible, since by
definition all fields must be less than 32K today, and so use a two-byte
pointer.
Next, add a new BIF (%indexsize?) to determine the number of bytes in the
index portion of a varying field. Programmers like you need to use this new
BIF in all new code, and must remember to fix any existing code when a
varying field size is changed.
For maximum backwards compatibility, IBM could implement a *ALLOWBIGVARYING
compile flag. This would default to *NO and if you unknowingly changed a
field's buffer size to a value that required a larger pointer (say through a
LIKE define or a /COPY) without actually changing the *ALLOWBIGVARYING flag
on the program, then the program wouldn't compile.
You'd go through, replace any offending code with %indexsize and then set
the *ALLOWBIGVARYING flag in the H specification.
(Of course, there are people who use a /COPY for their H spec and who would
go in and put *ALLOWBIGVARYING in the H spec without changing all affected
programs, thus defeating the purpose of the flag. Those people need to be
beaten with sticks.)
So what do we have?
1. 100% backward compatibility for existing code.
2. Automatic resizing of the pointer based on field definition.
3. A compiler flag to help avoid potential logic bombs.
All in all, not a bad solution. You still need to address the ALLOCUNIT
problem, but that's actually not pertinent to this specific issue.
Err... also, I'm not sure that we need a *MAX32KB. Is that just for
compatibility with older releases, or what?
It's for completeness. Whenever you allow an attribute that implicitly only
had one possible value to be explicitly configured, you should have keywords
for each possible value, and then allow the original implicit value to be
the default. That's basic backwards compatibility.
However, since in the situation I outlined above the pointer length is
implicit, not explicit, no keyword at all is needed and the question is
moot.
Joe
midrange.com
