Am 01.04.2014 01:16, schrieb Andrew Rowley:
On 1/04/2014 9:37, Bernd Oppolzer wrote:
How do you solve the problem that a pointer coming from a PL/1 module
(or ASSEMBLER) and possibly having the high order bit on is not accepted
from the C module as a valid pointer and that the results, if you
In
cae1xxdeqycdbu6n4y38jj8veuccappsokfxcadjwbkrpda5...@mail.gmail.com,
on 03/31/2014
at 10:49 AM, John Gilmore jwgli...@gmail.com said:
In PL/I, however, the parentheses are required (because PL/I has no
reserved words, only keywords in context). Thus
IF ARG = NULL then RETURN SYSNULL ELSE
typedef unsigned int PLI_PTR;
#define PLI_PTR_TO_C_PTR(p) (void *) ((p) == 0xFF00 ? 0 : (p)
0x7FFF)
usage example:
int func (PLI_PTR a, PLI_PTR b)
{
some_type *parm1 = PLI_PTR_TO_C_PTR (a);
another_type *parm2 = PLI_PTR_TO_C_PTR (b);
if (parm1 == NULL)
...
}
func in
of course, all those problems are easily solved when coding
some small ASSEMBLER subprograms. I did this in fact, when we
had some problems in the past with the 0C8 abends due to high
order bits set in passed addresses (call an ASSEMBLER subprogram
to switch OFF the PSW mask bit for 0C8 on entry
Sent: Tuesday, April 01, 2014 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
of course, all those problems are easily solved when coding some small
ASSEMBLER subprograms. I did this in fact, when we had some problems in the
past with the 0C8 abends due to high
John Abell would like to recall the message, Compiler error in z/OS C
compiler.
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
--
For IBM-MAIN subscribe
error in z/OS C compiler
Well we do not want to have to check to see if things are changed every time
we leave the building. We have more than enough to do as it is.
John T. Abell
President
International Software Products
Tel: 800-295-7608 Ext: 224
International: 1-416-593-5578
I found it in my archives, from 1995. External ASSEMBLER function,
callable from C - and PL/1 - , to switch the 0C8 mask bit on or off.
Some of you might understand the German comments.
*
**
* *
* SETFOFL - OC8-MASKENBIT AUS- ODER
On Tue, 1 Apr 2014 11:14:35 -0400, John Abell wrote:
John Abell would like to recall the message, Compiler error in z/OS C
compiler.
Paul Gilmartin would like to forget the message, Compiler error in z/OS C
compiler. If only he could.
--gil
John Gilmore wrote:
Implementation dependencies are in general undesirable, but
inter-language linkages of the kind being talked about here are always
and ineluctably doubly implementation-dependent.
Consider now the PL/I statements
declare pbs32_sysnull_image
static aligned bit(32)
John Abell wrote:
John Abell would like to recall the message, Compiler error in z/OS C
compiler.
Once posted in list-serv, always frozen solid in Internet fossils and all its
mirror sites for archival purposes.
Careful with that Send thing. At least your posts were not offensive... grin
In 533766af.3000...@t-online.de, on 03/30/2014
at 01:34 AM, Bernd Oppolzer bernd.oppol...@t-online.de said:
And my experience is that over 90 percent of them have
no clue what the descriptor logic of PL/1 is all about,
Nor should they. They should, however, understand the DECLARE
statement.
Of all the languages which I have personally used. I loved Borland's Delphi
(loosely base on Modula II) the best.
On Sun, Mar 30, 2014 at 8:22 AM, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net wrote:
In 533766af.3000...@t-online.de, on 03/30/2014
at 01:34 AM, Bernd Oppolzer
Just use C++ with has references
void func( int ref ) { ref++ }
On 30/03/2014 9:22 PM, Shmuel Metz (Seymour J.) wrote:
In 533766af.3000...@t-online.de, on 03/30/2014
at 01:34 AM, Bernd Oppolzer bernd.oppol...@t-online.de said:
And my experience is that over 90 percent of them have
no
On Mon, 31 Mar 2014 06:58:46 -0500, John McKown wrote:
Of all the languages which I have personally used. I loved Borland's Delphi
(loosely base on Modula II) the best.
I was absolutely blown away when I first saw Delphi - not so much with the
language itself, but that IDE !!! What an eye
On 31/03/2014 8:44 PM, Shane Ginnane wrote:
On Mon, 31 Mar 2014 06:58:46 -0500, John McKown wrote:
Of all the languages which I have personally used. I loved Borland's Delphi
(loosely base on Modula II) the best.
I was absolutely blown away when I first saw Delphi - not so much with the
On Mon, Mar 31, 2014 at 8:10 AM, David Crayford dcrayf...@gmail.com wrote:
On 31/03/2014 8:44 PM, Shane Ginnane wrote:
On Mon, 31 Mar 2014 06:58:46 -0500, John McKown wrote:
Of all the languages which I have personally used. I loved Borland's
Delphi
(loosely base on Modula II) the best.
On 31/03/2014 10:13 PM, John McKown wrote:
You will pleased to know that Lua on z will be coming this year
(compliments from my employers) with lots of goodies and execution speed
that can show Java a clean pair of heels in 8 out of 10 benchtests that run
sub-second.
I hate to have to ask, but
Subject: Compiler error in z/OS C compiler
Hello mainframe C users,
today I observed an error in the C compiler, which made me think again about
the optimization strategy of the z/OS C compiler.
I wrote a small C function; the purpose was to translate pointer values
coming from PL/1 modules from NULL
Many C programmers have the habit of, for clarity, enclosing the
returned expression of a RTETURN statement in parentheses, which C
neither requires no objects to.
In PL/I, however, the parentheses are required (because PL/I has no
reserved words, only keywords in context). Thus
IF ARG = NULL
Two typo corrections, for which I apologize:
o RTETURN == RETURN
o IF ARG = NULL then RETURN(SYSNULL) ELSE RETURN (ARG) ; ==
IF ARG = NULL then RETURN(SYSNULL) ; ELSE RETURN (ARG) ;
John Gilmore, Ashland, MA 01721 - USA
withdraw the suggestion.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Monday, March 31, 2014 8:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
Many C programmers have
We discussed this further with some co-workers on my customers site.
There are some more aspects of this discussion:
a) the C language manual at one certain point states what are pointers
acceptable
to C and what are not. From the wording there it sounds as if pointers
that come
from
On 3/31/2014 4:02 PM, Bernd Oppolzer wrote:
We discussed this further with some co-workers on my customers site.
There are some more aspects of this discussion:
a) the C language manual at one certain point states what are pointers
acceptable
to C and what are not. From the wording there it
Am 01.04.2014 00:11, schrieb Steve Comstock:
On 3/31/2014 4:02 PM, Bernd Oppolzer wrote:
We discussed this further with some co-workers on my customers site.
There are some more aspects of this discussion:
a) the C language manual at one certain point states what are pointers
acceptable
to C
On Mon, 31 Mar 2014 17:33:48 -0500, John Gilmore wrote:
... I do not think your
omisses, a semicolon and some framing parentheses, are mortal (or
indeed even venial) sins. Moreover, what you wrote is substantively
correct.
On the other hand I do think it important to correct code examples
On 1/04/2014 9:37, Bernd Oppolzer wrote:
How do you solve the problem that a pointer coming from a PL/1 module
(or ASSEMBLER) and possibly having the high order bit on is not accepted
from the C module as a valid pointer and that the results, if you use
this pointer,
are unpredictable or
John,
the problem is that if you initialize a PL/1 structure by simply writing
STRUCT = '';
and the structure contains pointers, these pointers are initialized
to NULL, not SYSNULL. Admitted: I did not check so far if there is
a compiler option to change this behaviour, but even if there was
Bernd,
Now that I have a better understanding of the full dimensions your
problem I will give it some further thought, and it may be that I will
be abe to make further suggestions.
In passing let me note that the usages
whatever = null() ;
whatever = sysnull() ;
are necessary and appropriate
; this failed because
of a compiler error in the z/OS C compiler (because the NULL() value
0xFF00 has the high order bit set, which lead to serious trouble
in the translation logic I chose. I found a workaround, but the compiler
error still needs to be fixed).
a) I know about the ability to omit
In 53369a68.4060...@t-online.de, on 03/29/2014
at 11:03 AM, Bernd Oppolzer bernd.oppol...@t-online.de said:
PL/1, BTW, does other strange things using descriptors,
FSVO strange. PL/I supports call by reference, and the
locator/descriptor is simply the mechanism used by current
Am 30.03.2014 00:41, schrieb Shmuel Metz (Seymour J.):
In 53369a68.4060...@t-online.de, on 03/29/2014
at 11:03 AM, Bernd Oppolzer bernd.oppol...@t-online.de said:
PL/1, BTW, does other strange things using descriptors,
FSVO strange. PL/I supports call by reference, and the
?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Thursday, March 27, 2014 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
I wonder if C99 intptr_t and uintptr_t would
I examined the problem further, using the following code:
#include stdio.h
#include stdlib.h
#include string.h
/**/
/* */
/* PLI/1 NULL () = SYSNULL () */
/* */
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
Bernd,
ISTM that the url provided by Charles Mills yesterday evening to the
securecoding.cert.org site is right on target. The example on that page
about using type uintptr_t would seem to apply exactly to your case. If I
] On Behalf
Of Farley, Peter x23353
Sent: Friday, March 28, 2014 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
Bernd,
ISTM that the url provided by Charles Mills yesterday evening to the
securecoding.cert.org site is right on target. The example on that page
Bernd Oppolzer wrote:
Thank you all for your valuable suggestions.
The compiler is z/OS XL/C V1.13 and V1.11 -
well, in fact, I didn't test it with the 1.11. version.
I observed the problem on the site with the 1.13 version.
This is part of the PL/1 interface for my XML parser.
I had to do a
Farley, Peter x23353 wrote:
And sorry for the typo, that if statement should have read:
if (ppli == (uintptr_t) 0xff00u)
Not unitptr_t.
Peter
I'm not sure uintptr_t is going to make much difference...
it's just a typedef to (unsigned long). It _should_ be completely
equivalent to
Before I get some remarks on this:
I just realized that NULL returning 0xFF00 was designed when we
still had 24 bit addressing, so there must have been other reasons
for this design decision.
Am 28.03.2014 14:39, schrieb Bernd Oppolzer:
The unsigned int in my case is large enough to take
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Friday, March 28, 2014 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
Bernd,
ISTM that the url provided by Charles Mills yesterday evening
On 28 March 2014 09:47, Bernd Oppolzer bernd.oppol...@t-online.de wrote:
I just realized that NULL returning 0xFF00 was designed when we
still had 24 bit addressing, so there must have been other reasons
for this design decision.
I remember heated discussions on this matter at my
Bernd,
I do not know what control you have over user code that invokes yours,
but PL/I has for long supported the use of sysnull rather than null,
i.e., '0'B4 instead of 'FF00'B4 as the null,
points-nowhere, EOL, pointer value.
Moreover, a PL/I preprocessor procedure that 1) replaces
Hello mainframe C users,
today I observed an error in the C compiler,
which made me think again about the optimization strategy
of the z/OS C compiler.
I wrote a small C function; the purpose was to translate
pointer values coming from PL/1 modules from NULL() values
- PL/1 builtin NULL()
On Thu, Mar 27, 2014 at 10:51 AM, Bernd Oppolzer bernd.oppol...@t-online.de
wrote:
Hello mainframe C users,
today I observed an error in the C compiler,
which made me think again about the optimization strategy
of the z/OS C compiler.
I wrote a small C function; the purpose was to
Sorry, I missed that you already did that.
On Thu, Mar 27, 2014 at 11:05 AM, John McKown
john.archie.mck...@gmail.comwrote:
On Thu, Mar 27, 2014 at 10:51 AM, Bernd Oppolzer
bernd.oppol...@t-online.de wrote:
Hello mainframe C users,
today I observed an error in the C compiler,
which made
treats the code?
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bernd Oppolzer
Sent: Thursday, March 27, 2014 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Compiler error in z/OS C compiler
Hello mainframe C users,
today
, 2014 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
Perhaps turn off optimization and see what the raw compiler produces?
That may provide a hint to a solution, or it may just leave the function to
do what you want and you will have accomplished your task.
BTW
Thank you all for your valuable suggestions.
The compiler is z/OS XL/C V1.13 and V1.11 -
well, in fact, I didn't test it with the 1.11. version.
I observed the problem on the site with the 1.13 version.
This is part of the PL/1 interface for my XML parser.
I had to do a rollout today on three
static function, because the function is only of local interest
and should not be visible to the linkage editor (that's the way
to do this in C - they saved keywords - that's a sad story;
external functions are static, too. It would be much better,
if there was a keyword local to express the same
https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/ab_use_of_the_ansi_c_aliasing_rules?lang=en
On 27 Mar 2014, at 11:51 pm, Bernd Oppolzer bernd.oppol...@t-online.de
wrote:
Hello mainframe C users,
today I observed an error in the C compiler,
I wonder if C99 intptr_t and uintptr_t would solve the problem.
On 28 Mar 2014, at 6:42 am, Charles Mills charl...@mcn.org wrote:
https://www.securecoding.cert.org/confluence/display/seccode/INT36-C.+Conver
ting+a+pointer+to+integer+or+integer+to+pointer
@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Thursday, March 27, 2014 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiler error in z/OS C compiler
I wonder if C99 intptr_t and uintptr_t would solve the problem.
--
For IBM
On Thu, Mar 27, 2014 at 12:31 PM, Bernd Oppolzer bernd.oppol...@t-online.de
wrote:
Thank you all for your valuable suggestions.
The compiler is z/OS XL/C V1.13 and V1.11 -
well, in fact, I didn't test it with the 1.11. version.
I observed the problem on the site with the 1.13 version.
That looks good and indeed more naturally to me,
I will give it a try ... tomorrow.
Thank you.
Bernd
Am 28.03.2014 00:44, schrieb Charles Mills:
I wonder, what if the OP reversed the casting and instead coded
if ( ptr == (void *)0xff00 ) ...
Is that legal? (Can you cast a constant to a
Am 28.03.2014 02:41, schrieb Sam Siegel:
Enclose memcmp in parenthesis, (memcmp)(...), to force the compile to
generate code which calls memcmp instead of generating inline code.
This was the workaround I found for the original problem,
and it worked perfectly; I like the memcmp being
On 28/03/2014 1:05 AM, Thomas David Rivers wrote:
The IBM compiler could be misapplying range optimizations, assuming
that a 31-pointer is in the range [0x0 .. 0x7fff] and therefor could
never be equal to 0xff00... but, that would be quite a stretch.
If they are doing this, I can bet
56 matches
Mail list logo
