/STANDARD=VAXC & DSC$K_DTYPE_T

[B Claremont]

Alpha VMS 8.2
DEC C V6.5-001-48BCD

I ran across a problem with a C program compiled with DEC C using the /STANDARD=VAXC qualifier. There is a descriptor in the program defined as type DSC$K_DTYPE_T and class DSC$K_CLASS_S. I should be able to assign this descriptor a length ranging from 0 to 65535. However, when compiled using the /STANDARD=VAXC qualifier, any length beyond 4464 defaults to 4464. Lesser values work as expected, i.e. a length of 1024 is assigned as expected. Values above 4464 are assigned as 4464 without any information, warning, or error messages being issued.

If I remove the /STANDARD=VAXC qualifier, the problem goes away.

Mostly to satisfy my curiosity, can anyone shed any light on the issue? Is it a know limitation or bug?

Thanks

P.S. - Sorry, but I can't post the code related to this issue.

[Hein van den Heuvel]

Hi there Bruce,

That's the most boring descriptor there is, a basic piece of static string, as for example setup by $DESCRIPTOR.

You gotta do better than that if you want us to try to help.
Even if you can not post the code, you gotta post the snippets around the descriptor declaration and usage.
Better still... create a reproducer based on the code?

At this point it is not clear (to me) how you assign the length or how do you determin is is incorrect.

Can you share debugger output from the examine for the descriptor?

Is there an error message somewhere?

I seem to recall that writeable string constants where was a /STAN=VAXC difference which tripped folks over. Check out the HELP CC/ASSUM

"[NO]WRITABLE_STRING_LITERALS

Stores string constants in a writable psect. Otherwise, such
constants will be placed in non-writable psect.

For /STANDARD=VAXC or /STANDARD=COMMON, the default is
/ASSUME=WRITABLE_STRING_LITERALS. For all other compiler
modes, the default is /ASSUME=NOWRITABLE_STRING_LITERALS."

of course I have no clue how that might apply to your case.

Cheers,
Hein.

[Steven Schweda]

I find it more satisfying to adjust the code
so that /STANDARD=VAXC is not needed, but,
offhand, I can't imagine how it could have
the effect you claim it does. Off the other
hand, it's not entirely clear exactly what
you're describing.

> [...] can anyone shed any light on the
> issue?

_You_ could.

> Sorry, but I can't post the code related to
> this issue.

But you seem unwilling to.

Sorry, but because 4464 is not a magic value
that I recognize, without exhibiting a
failing test case, preferably a small one,
I'd guess that it's unlikely that you'll get
an explanation. (You _certainly_ won't get
one from me. Perhaps some psychic can do
better.)

[Robert Gezelter]

Bruce,

I must concur with Hein and Steve, 4464 is not a magic number, and several things could be happening.

A reproducer (or the listing of the relevant lines in the MACHINE_CODE listing) might go a long way towards at least understanding what is happening. Having debugged many such problems over the years, I can testify that they are almost always apparent once the actual machine code is understood.

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> [...] actual machine code [...]

Machine code???!!!

I'd settle for a clear description of the
_problem_ (and a bit of source code). I have
no idea what "any length beyond 4464 defaults
to 4464" means. Not knowing what anything
actually was, nor how anything was actually
set to any value, nor how the (defective?)
result was observed, I would be reluctant to
waste any more time pondering this mystery,
especially if the only clue offered was some
scrap of machine code. Call me lazy.

[B Claremont]

Basically, I just wondered if anyone had seen a similar problem. It all began with a buffer overflow in the application that I traced back to the buffer size. The size is defined by the problem descriptor. If dropping the VAXC qualifier solves the problem, I'm good.

Here's a bit more information.

Descriptor from program listing showing macro expansion.

19345 GLOBAL(symbuf, 0, ALPHA, DSC$K_DTYPE_T, XYZSMB, NULL)
E DESCR symbuf = { 65535, 14, 1, ((void *) 0), 0, 0x01, 0, 0, ((void *) 0)};

Compiled with /STANDARD=VAXC and examined at program initiation using DEBUG:

XYZ\symbuf
dsc_length: 4464
dsc_datatype: 14
dsc_class: 1
dsc_address: 0
dsc_flags: 0
dsc_type: 1
dsc_idp: 0
dsc_ndim: 0
dsc_dimp: 0


Compiled without /STANDARD=VAXC and examined at program initiation using DEBUG:

XYZ\symbuf
dsc_length: 65535
dsc_datatype: 14
dsc_class: 1
dsc_address: 0
dsc_flags: 0
dsc_type: 1
dsc_idp: 0
dsc_ndim: 0
dsc_dimp: 0

[Steven Schweda]

> Here's a bit more information.

Not enough (for me). For example, what's
DESCR?

> [...] I'm good.

That's one opinion. "Content" and "good" are
spelled differently for a reason.

[Hein van den Heuvel]

( Hmmm... 2 points... looks like you do not understand the problem nor the answer :-).

Hmmm, looks like there are a bunch of macros involved.

That is not a simple string descriptor you show us
It seems application defined stuff which looks like strign descriptor.
A simple string has just one address right?

Typically a string descriptor initialization macro uses something like: sizeof(string)-1

What is the object in the macro?
I guess the XYZSYM, not the ALPHA.
What does sizeof(XYZSYM) give?

If it shows 4464, then the problem is not with the descriptor, but with the data defintion itself which is more likely anyway.

What is the ALPHA supposed to do?

>> If I remove the /STANDARD=VAXC qualifier, the problem goes away.

Nah, it just becomes less visible.

But like Steve suggests... maybe it is more fruitful to figure out why the VAXC override is used and fix that!

Hope this helps some,
Hein.

[Hoff]

Most folks are headed the other way. From VAX C to ANSI C...

C code built with /STANDARD=VAXC is, at least by conventional assumption if not almost by definition, buggy.

I'd get rid of the qualifier. When moving forward, I'd fix the errors that the newer compilers tend to detect and report, too -- some folks leave these errors and diagnostics in the C code, but that's not something I prefer to do. Yes, there will be various diagnostics moving from typical VAX C to ANSI (DEC / Compaq / HP) C code, but there'll almost certainly be diagnostics given the changes to the C standards and practices over the years.

Occam's Razor would tend to imply this is not the descriptor. Text descriptors are used all over the place; just too often. On no evidence -- the output from the compiler /SHOW=EXPANSION (whatever it's called) would be useful here, and include the definitions of the related macros and data structures in what's excerpted here -- I'd tend to assume something is stomping on the descriptor, or there's something odd in how the (I assume) external- (extern) or the module-level (static) scope structures are initialized. If you can extract all of the relevant code out into a small module that you can post...

And a raw byte dump (within the debugger) can be relevant, too. The debugger knows about the padding implicit within a structure when it displays the contents, and the dump shows any padding that might be lurking. And this descriptor is a composite; it's being used as a string descriptor here, but there are fields which imply other uses and other types of descriptors are used.

There have been a few odd errors fixed over the years, too. Is the system current on the V8.2 ECO kits? C V7.3 is current -- and there are a number of mandatory ECO kits for V8.2, too.

Stephen Hoffman
HoffmanLabs LLC

[Robert Gezelter]

Steve,

In a prior lifetime, I was involved in implementing and debugging code generators (on other platforms). I quickly determined that when strange results appeared, it was not that difficult, when presented with strange behavior, to take a look at the generated code. It was not unusual to gain better understanding of a source level error by seeing what the compiler actually generated! One case involving an important COBOL program turned was particularly entertaining: a typo in a structure layout that had been missed for quite a while!

Bruce,

Without the source or the machine listing, it is particularly difficult to gain an understanding of what is happening. If confidentiality is an issue, perhaps ITRC is not the best venue [disclose: My firm does provide services in this area.]

- Bob Gezelter, http://www.rlgsc.com