Re: XL C\C ++ sizeof of datatypes
On 2020-04-26 2:13 PM, Thomas David Rivers wrote:
There's a lot being thrown around here
However, there _are_ places in the C language where the compiler must
fold constants at compile time, e.g.:
enum tag { one = (1+0), two = (1+1+0) };
That is obliged to compile and the compiler most compute those
additions to provide the proper values for the "one" and "two"
enumeration
constants.
The C standard has more details about this. So most compilers will
easily handle most constant computions (there are several corners
that are interesting to consider... probably only interesting to
compiler writers :-) )
It seems there were plenty of other answers about the vagaries
of parameters and default integer promotions, etc...
Great post (from an expert)! default integer promotions can be
particularly treacherous!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
If operand is a type (as opposed to variable name), the parentheses are required. If the operand is an expression (including a solitary variable name), the parentheses are optional. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Seymour J Metz > Sent: Monday, April 27, 2020 3:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: XL C\C ++ sizeof of datatypes > > I don't understand why, but after listing it as an operator K&R gives it as "sizeof (size > of an object)" and all of the examples have parentheses around the type. Of course, > something like "sizeof (struct tnode) " really does need the parentheses. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf > of Farley, Peter x23353 > Sent: Monday, April 27, 2020 1:30 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: XL C\C ++ sizeof of datatypes > > Joe, > > In C the "sizeof" keyword is an OPERATOR, not a function. Instead of > "sizeof(shorttype)" you should code "sizeof shorttype". > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Sunday, April 26, 2020 9:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: XL C\C ++ sizeof of datatypes > > HI > >I am looking in the XL C docs lang reference user guide programming guide > > For the length of the following data types > > Short , int long and I cannot seem to find it > > frustrated > > I coded a program > > Int len; > > Unsigned short shortype; > > Int len = sizeof(shorttype); > >But the compiler seemed to comment the above statement and not > generate the assembler ps (I am running metal c); > > Any help appreciate it > -- > > This message and any attachments are intended only for the use of the addressee and > may contain information that is privileged and confidential. If the reader of the > message is not the intended recipient or an authorized representative of the intended > recipient, you are hereby notified that any dissemination of this communication is > strictly prohibited. If you have received this communication in error, please notify us > immediately by e-mail and delete the message and any attachments from your system. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
You may see the operator with parentheses more often than without but that does not change the nature of the keyword. Any function with the same name as a keyword causes undefined behavior. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Charles Mills > Sent: Monday, April 27, 2020 2:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: XL C\C ++ sizeof of datatypes > > I think both are correct, and in my experience I have seen the function much > more than the operator. > > https://www.educative.io/edpresso/what-is-the-sizeof-function-in-c > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Farley, Peter x23353 > Sent: Monday, April 27, 2020 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: XL C\C ++ sizeof of datatypes > > Joe, > > In C the "sizeof" keyword is an OPERATOR, not a function. Instead of > "sizeof(shorttype)" you should code "sizeof shorttype". > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of > Joseph Reichman > Sent: Sunday, April 26, 2020 9:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: XL C\C ++ sizeof of datatypes > > HI > >I am looking in the XL C docs lang reference user guide programming guide > > For the length of the following data types > > Short , int long and I cannot seem to find it > > frustrated > > I coded a program > > Int len; > > Unsigned short shortype; > > Int len = sizeof(shorttype); > >But the compiler seemed to comment the above statement > and not generate the assembler ps (I am running metal c); > > Any help appreciate it > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Seymour J Metz wrote: The difference is that sizeof is parsed as an operator. Sometimes programs have parameterized declarations and the compiler must generate code to calculate sizeof. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 This is true - for C99 variable length arrays. That was made an optional feature of the latest standards, because it turns out to not be the best idea. Hopefully it will go away completely in the future. The basic problem is the one of "catching" an out-of-memory situation, C doesn't have any recourse in this case except to blow-up with an out-of-stack (which generally causes a SIGSEGV on many platforms, an ABEND 978 in the Dignus runtime.) Whereas, a program can easily malloc() memory and check for NULL and "do something" if there isn't sufficient memory. (You _can_ set up an alternate signal stack and catch these issues, but you can't continue the program's execution from them.) C variable arrays were touted as a portable way to accomplish what the non-portable alloca() function does in many implementations. But, the common alloca() will return NULL if there is no space... so, it's probably a better approach. C variable-length arrays are the only time sizeof() isn't a compile-time constant. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Charles Mills wrote:
Is that true? I know the first part is true: sizeof(foo) or sizeof foo is
evaluated at compile time, not run time. But "not invoked until run time" is
also true for most operators, right? a + b is *generally* evaluated at run
time.
I have a user-defined macro #define elementsof(a) sizeof(a)/sizeof(a[0]). Is
that a function or an operator? It is certainly a "function-type macro."
Charles
There's a lot being thrown around here
However, there _are_ places in the C language where the compiler must
fold constants at compile time, e.g.:
enum tag { one = (1+0), two = (1+1+0) };
That is obliged to compile and the compiler most compute those
additions to provide the proper values for the "one" and "two" enumeration
constants.
The C standard has more details about this.So most compilers will
easily handle most constant computions (there are several corners
that are interesting to consider... probably only interesting to
compiler writers :-) )
It seems there were plenty of other answers about the vagaries
of parameters and default integer promotions, etc...
- Dave Rivers -
--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
The difference is that sizeof is parsed as an operator. Sometimes programs have parameterized declarations and the compiler must generate code to calculate sizeof. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Pew, Curtis G Sent: Monday, April 27, 2020 6:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes On Apr 27, 2020, at 5:29 PM, Charles Mills wrote: > > I guess it's an operator but it sure as heck looks like a function. > > If it walks like a duck and quacks like a duck ... > -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Is that true? I know the first part is true: sizeof(foo) or sizeof foo is evaluated at compile time, not run time. But "not invoked until run time" is also true for most operators, right? a + b is *generally* evaluated at run time. I have a user-defined macro #define elementsof(a) sizeof(a)/sizeof(a[0]). Is that a function or an operator? It is certainly a "function-type macro." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Monday, April 27, 2020 3:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes On Apr 27, 2020, at 5:29 PM, Charles Mills wrote: > > I guess it's an operator but it sure as heck looks like a function. > > If it walks like a duck and quacks like a duck ... > The distinction is that sizeof is calculated by the compiler during compilation. A function is not invoked until run time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Apr 27, 2020, at 5:29 PM, Charles Mills wrote: > > I guess it's an operator but it sure as heck looks like a function. > > If it walks like a duck and quacks like a duck ... > The distinction is that sizeof is calculated by the compiler during compilation. A function is not invoked until run time. -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
https://www.quora.com/How-is-sizeof-an-operator-but-not-a-function-Can-you-g ive-source-code-for-it I guess it's an operator but it sure as heck looks like a function. If it walks like a duck and quacks like a duck ... Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, April 27, 2020 3:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes I believe that edpresoso is wrong and that sizeof is always an operator, never a function, despite the parentheses. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
I believe that edpresoso is wrong and that sizeof is always an operator, never a function, despite the parentheses. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Monday, April 27, 2020 5:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes I think both are correct, and in my experience I have seen the function much more than the operator. https://secure-web.cisco.com/17gpmDBkWzqWqGMhxvhYOL7Gh6Los9fw28x1TitarKIHN9PktFSwcSUXStjw8dG_ilzFTV9oIEmChXP4bSfdMZQTg6GRchPfD0-p_Ri_PfWzu-NJYlgrCKK-eBslsxUN7e_HmExhAJvllwMqOYz1PVSDLZzU8dfgd5fj8kKClVhjpZkb_eEKadi94x7T0Vuzt6PhHlIdO_sPTZTSylNnlGnVn0GOAMdgNlsUYjq4Xs3dS3ODTNRx1vs02xI1C7ZUg5jj_uKia1sbIFDHNGFHU99GCM8XwyvX4y8cIIr8nitz6Ihc8S3QhSlSvqbSeE7DI7V2hEApbjOm6y1OrDu_UlNTvbeLCILmgF8GLr4xkuCroXB_9RWufG3jf9x14b76UAXG0czxLyK6hjZDWh8dIbO1x2acDyBPo4636NjsgSftsHcqr0OrAdf9KXIiFchBFoFKYtxcFpQkZkMFfVm5pDA/https%3A%2F%2Fwww.educative.io%2Fedpresso%2Fwhat-is-the-sizeof-function-in-c Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, April 27, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes Joe, In C the "sizeof" keyword is an OPERATOR, not a function. Instead of "sizeof(shorttype)" you should code "sizeof shorttype". Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Sunday, April 26, 2020 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XL C\C ++ sizeof of datatypes HI I am looking in the XL C docs lang reference user guide programming guide For the length of the following data types Short , int long and I cannot seem to find it frustrated I coded a program Int len; Unsigned short shortype; Int len = sizeof(shorttype); But the compiler seemed to comment the above statement and not generate the assembler ps (I am running metal c); Any help appreciate it -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
I don't understand why, but after listing it as an operator K&R gives it as "sizeof (size of an object)" and all of the examples have parentheses around the type. Of course, something like "sizeof (struct tnode) " really does need the parentheses. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Monday, April 27, 2020 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes Joe, In C the "sizeof" keyword is an OPERATOR, not a function. Instead of "sizeof(shorttype)" you should code "sizeof shorttype". Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Sunday, April 26, 2020 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XL C\C ++ sizeof of datatypes HI I am looking in the XL C docs lang reference user guide programming guide For the length of the following data types Short , int long and I cannot seem to find it frustrated I coded a program Int len; Unsigned short shortype; Int len = sizeof(shorttype); But the compiler seemed to comment the above statement and not generate the assembler ps (I am running metal c); Any help appreciate it -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
I think both are correct, and in my experience I have seen the function much more than the operator. https://www.educative.io/edpresso/what-is-the-sizeof-function-in-c Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, April 27, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes Joe, In C the "sizeof" keyword is an OPERATOR, not a function. Instead of "sizeof(shorttype)" you should code "sizeof shorttype". Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Sunday, April 26, 2020 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XL C\C ++ sizeof of datatypes HI I am looking in the XL C docs lang reference user guide programming guide For the length of the following data types Short , int long and I cannot seem to find it frustrated I coded a program Int len; Unsigned short shortype; Int len = sizeof(shorttype); But the compiler seemed to comment the above statement and not generate the assembler ps (I am running metal c); Any help appreciate it -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Joe, In C the "sizeof" keyword is an OPERATOR, not a function. Instead of "sizeof(shorttype)" you should code "sizeof shorttype". Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Sunday, April 26, 2020 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XL C\C ++ sizeof of datatypes HI I am looking in the XL C docs lang reference user guide programming guide For the length of the following data types Short , int long and I cannot seem to find it frustrated I coded a program Int len; Unsigned short shortype; Int len = sizeof(shorttype); But the compiler seemed to comment the above statement and not generate the assembler ps (I am running metal c); Any help appreciate it -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Am 27.04.2020 um 13:46 schrieb Seymour J Metz:
But can you use a character as an initial or limit value in a DO? That's
possible in some other languages.
yes:
for ch := 'A' to 'Z' do
writeln ('character with ord = ', ord (ch), ' appeared ', howoften
[ch]);
I did not use this in the example below, because I wanted to cover the
complete range of char
and both CHR (0) and CHR (255) are not printable characters.
The coding above is not really portable, because in ASCII there are 26
chars between 'A' and 'Z',
but in EBCDIC, there are more :-)
BTW: I extended Stanford Pascal long ago to support hexadecimal
notation, so I could code
my original example as:
for ch := X'00' to X'FF' do
writeln ('character with ord = ', ord (ch), ' appeared ', howoften
[ch]);
without the need for the conversion functions.
There again, I had to take care of the incompatibiliy between char and
integer types:
X'FF' is a char hexadezimal constant
0xFF is an integer hexadezimal constant
http://bernd-oppolzer.de/job9i029.htm
Kind regards
Bernd
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Monday, April 27, 2020 3:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
Am 27.04.2020 um 05:56 schrieb Paul Gilmartin:
On Mon, 27 Apr 2020 04:23:49 +0200, Bernd Oppolzer wrote:
On the other hand, Pascal supports ANY standard or scalar or subrange
type as index type
for arrays, for example:
var howoften : array [char] of integer ;
ch: char;
...
read (ch);
howoften [ch] := howoften [ch] + 1;
the array howoften is used to count the occurence of chars in an input
file, for example.
But can you use a char as a control variable of DO to
step through the howoften array?
yes:
for ch := chr (0) to chr (255) do
writeln ('character with ord = ', ord (ch), ' appeared ', howoften
[ch]);
I used ord here because not all chars are printable ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Oppolzer-Informatik
Dipl. Inf. Bernd Oppolzer
Bärenhofstraße 23
70771 Leinfelden-Echterdingen
—
Tel.: +49 711 7949591
priv.: +49 711 7949590
mobil: +49 151 75005359
eMail: bernd.oppol...@t-online.de <mailto:bernd.oppol...@t-online.de>
Web: http://bernd-oppolzer.de/job.htm
—
Für Umsatzsteuerzwecke:
SteuerNr.: 97 076 / 29921
USt-ID-Nr.: DE 147 700 393
—
Oppolzer-Informatik 1983 - 2019
36years of experience in computer science**
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
But can you use a character as an initial or limit value in a DO? That's
possible in some other languages.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Monday, April 27, 2020 3:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
Am 27.04.2020 um 05:56 schrieb Paul Gilmartin:
> On Mon, 27 Apr 2020 04:23:49 +0200, Bernd Oppolzer wrote:
>
>> On the other hand, Pascal supports ANY standard or scalar or subrange
>> type as index type
>> for arrays, for example:
>>
>> var howoften : array [char] of integer ;
>> ch: char;
>> ...
>> read (ch);
>> howoften [ch] := howoften [ch] + 1;
>>
>> the array howoften is used to count the occurence of chars in an input
>> file, for example.
>>
> But can you use a char as a control variable of DO to
> step through the howoften array?
yes:
for ch := chr (0) to chr (255) do
writeln ('character with ord = ', ord (ch), ' appeared ', howoften
[ch]);
I used ord here because not all chars are printable ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Am 27.04.2020 um 05:56 schrieb Paul Gilmartin:
On Mon, 27 Apr 2020 04:23:49 +0200, Bernd Oppolzer wrote:
On the other hand, Pascal supports ANY standard or scalar or subrange
type as index type
for arrays, for example:
var howoften : array [char] of integer ;
ch: char;
...
read (ch);
howoften [ch] := howoften [ch] + 1;
the array howoften is used to count the occurence of chars in an input
file, for example.
But can you use a char as a control variable of DO to
step through the howoften array?
yes:
for ch := chr (0) to chr (255) do
writeln ('character with ord = ', ord (ch), ' appeared ', howoften
[ch]);
I used ord here because not all chars are printable ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Mon, 27 Apr 2020 03:35:46 +, Seymour J Metz wrote: >K&R did not require char to be at least 8 bits, but ANSI did. > >I wonder what C did on a ones' complement machine if a string contained a -0 >character? > POSIX specifies that the component characters should be compared as if unsigned. Grrr. Pascal on CDC 6600 (its birthplace) had the idiosyncratic type ALFA, a 60-bit word containing ten 6-bit characters. Comparison operators on ALFAs treated then as 60-bit signed integers. 6600 had no hardware compare instruction, so relational operators on ALFAs did a (ones-complement) subtraction and checked the sign. My co-worker complained to Wirth, I don't know with what effect. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Mon, 27 Apr 2020 04:23:49 +0200, Bernd Oppolzer wrote: >I would like to add: > >as explained, the types integer and char are incompatibel in Pascal. >Furthermore, char in Pascal is NOT a computational type; you cannot do >arithmetic with chars, and there is no sign with chars (much the same as >in PL/1, >for example). To do arithmetic with chars, you need the conversion >functions ORD and CHR. > But pred() and succ() operate on any ordinal type. >This all seems quite natural to me; the C idea that chars are small >integers and therefore have a sign is strange IMO. > UCSD Pascal introduced a strange convention. AND and OR operated bitwise on 16-bit boolean operands. ODD() simply returned its 16-bit argument, unmasked, and ORD(boolean) did likewise. IF tested only the lowest bit, so it interacted properly with ODD. But I encountered a problem when I used ARRAY [BOOLEAN] and used the value of ODD(integer) as a subscript. Apple patched the problem by masking when a boolean was used as a subscript. But this left misbehaviors such as ORD(ODD(2))>ORD(ODD(1)) >On the other hand, Pascal supports ANY standard or scalar or subrange >type as index type >for arrays, for example: > >var howoften : array [char] of integer ; > ch: char; >... >read (ch); >howoften [ch] := howoften [ch] + 1; > >the array howoften is used to count the occurence of chars in an input >file, for example. > But can you use a char as a control variable of DO to step through the howoften array? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
K&R did not require char to be at least 8 bits, but ANSI did.
I wonder what C did on a ones' complement machine if a string contained a -0
character?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Sunday, April 26, 2020 9:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
First of all, char in C is a subtype of int,
which means that you can do normal arithmetic operations to chars
and that chars are allowed in int expressions without special action
needed.
for example:
char c;
c = 'A' + 1; /* c will be 'B' */
c = c - 'A' + 'a'; /* c will now be 'b' - lower case */
Compare this to Pascal for example, where char and integer are two
different and
incompatible types. To do the same as above in Pascal, you need
conversion functions
(which are part of the Pascal standard):
var c: char;
c := chr (ord ('A') + 1);
c := chr (ord (c) - ord ('A') + ord ('a'));
Back to C:
Now, because chars are small ints in C (much like shorts), they can of
course be signed or unsigned.
If we have 8 bit bytes (which is normal on today's machines, but C would
of course support other
architectures, too), the ranges are -128 .. 127 for signed char (2's
complement) and 0 .. 255 for unsigned char.
If you code
char c;
like in the example above, the char is always signed or unsigned
depending on the default
active during compilation (can probably be modified by compiler option;
if not, there will
be a "factory" setting).
This "factory" setting is unsigned for IBMs z/OS compilers, and signed
for most Windows
and Unix compilers I am aware of.
The reason may be the EBCDIC character set; if signed were used with
EBCDIC, all the
normal characters and digits (X'C1' = 'A', X'F0' = '0') would have
negative char values.
So in my opinion the choice of the unsigned char default is natural for
EBCDIC machines.
The difference between this default has some implications for programs
that want to run
on both platforms (mainframe and PC, for example). I usually cope with
this by explicitly
specifying unsigned char, wherever necessary (only at places, where
computing is done
with character values, for example, when doing hexadecimal output of
storage areas
on both platforms).
BTW: if you want to take a closer look at Pascal, you can find the New
Stanford Pascal Compiler here:
http://secure-web.cisco.com/1ahRAh4N0CSp3gLQZrp-JRlfXHuhuDJQujTXuyt8e3kumDDxT7dDKWO8t8_IBUAYCYZyLxfUBnwWz9AwzGhs7pY99lm_vNvygdilxhlMNOGtSdRImFi-xm9IBnOx249ReXimPEwcmty0CAqDG3LMdyV9rMaKo-Iv6I982Iy_puqJIAAg5OO6aYswgnuVKyNZ3-XRvrm13YGxgkUS0BVP-QPOak9ypU0Mg-1GGxrp8AAw-cmYOzTzNSk1c_pthmqWbtIXAbkgZ7QL5WWm1u6ps0HyKQtC1KIcOviAiEtwR0GSGLBjtDt6kpRT6CFLbkpoP3P6vsM-LLTCKUDcOtsIvCRjbzx1jVP2Creo15L8gE2UoLsF9Dkp23xyAd_wjsHmjgp42wVi8QP-6Rl3jBZkMr519keflDI1nK_klJsTCBzzRjxn3gFq4y2NUyLS6P8rM/http%3A%2F%2Fbernd-oppolzer.de%2Fjob9.htm
https://secure-web.cisco.com/1hHx-M_IeANqdDOt3iYTGkb4FtQQe_aZgDhl66rbSBupoailYOTGHN-d9MY51K9niLKgvpdPWdlhUWsbFRry3TkOzXNALYs_fgVIhkeFhhOEtCUyFdrUT-6IigbGf61pRlye3y62ZlCvF7jlgtoXJvooyUG-uH5Cy9NheskLIXVad3akNA0pg4VqMCIdmPWoDWnbeClK9iq55QfVAi5ixx5NjHqCwUNmh3S8e2eivPmMUhQivNqmLO5JvVehmJAQKf1GjVLhc4k_HGxo7_9_wawW_D0z5nslZSmuBkIKyRxS0pCpvvOFr12jWiuGi6UzKrfaddOW8u62cFsvQUDWbsWO3NaCnz88FwpI4gYJZKR6O1VojfhyTELYB-5sYijvxjvkxBc3kEuz2tVGEwQxiv7ZDBKk11hab85IkWTKha9AWUC_Cc1ylxbj6421yHtcc/https%3A%2F%2Fgithub.com%2FStanfordPascal
https://www.facebook.com/StanfordPascal
which runs on IBM Mainframes (MVS and CMS) and on Windows, Unix (Linux),
OS/2, MacOS etc.;
on the Mainframe, 370 machine code is generated. On the other platforms,
the generated P-Code
is interpreted. The P-Code interpreter PCINT is written in C and (of
course) has to use unsigned chars
to implement the P-instructions in exactly the same way as they are
compiled on the mainframe.
Kind regards
Bernd
Am 26.04.2020 um 23:44 schrieb Charles Mills:
> Without testing, I think that a signed char argument satisfies and unsigned
> char formal parameter, but that &signed char does not satisfy unsigned char *.
>
> There is some C messiness
> https://www.facebook.com/StanfordPascal/?eid=ARDEjQaZgVZL2fivkB0AXGk_-mZF97XV3mESzaJ0RR-2NKu0jyroGwFbXt9kqk5UUIUCiHV9d0w2XcfUaround
> char signage. I think on most platforms char is kind of the same as signed
> char, but not exactly the same. On Z a char is kind of the same as an
> unsigned char, but not exactly the same. I am obviously fuzzy on the exact
> details, and no doubt someone will be happy to set me straight.
>
> Charles
--
For IBM-MAIN subscribe / signoff / archive access instructio
Re: XL C\C ++ sizeof of datatypes
Am 27.04.2020 um 04:21 schrieb Paul Gilmartin:
On Mon, 27 Apr 2020 03:49:00 +0200, Bernd Oppolzer wrote:
First of all, char in C is a subtype of int,
which means that you can do normal arithmetic operations to chars
and that chars are allowed in int expressions without special action
needed.
for example:
char c;
c = 'A' + 1; /* c will be 'B' */
c = c - 'A' + 'a'; /* c will now be 'b' - lower case */
Agreed. Yet no such compatibility exists among unsigned char *,
signed char *, and char*. However, many implementations quietly
ignore violations of this. I encountered this on IBM mainframe when
a FOSS program attempted to call a (standard, such as strlen()?)
function expecting a char * argument with an unsigned char *.
The intrinsic type of "XYZ" here is char *, not unsigned char *, and
surely not signed char *.
Yes,
the compiler flags functions calls where unsigned char * arguments (for
example)
are passed to char * parameters, even if the default signage for char is
unsigned -
usually a warning. There is in fact no difference between the types on
z/OS (given the
unsigned default), but there would be a difference when compiled on
other platforms.
The compiler issues the warning anyway. Of course, you can ignore such
warnings.
AFAIK, the ANSI functions like strlen, strcmp etc. have char *
parameters (no signage specified),
so the problem arises if you pass unsigned char pointers or arrays to
them. The problem IMO
would also occur, if you would pass explicitly signed char pointers or
arrays.
You can get rid of the warnings by casting your arguments:
x = strlen ((char *) my_unsigned_string);
OTOH, if you write own functions which must process a passed string as a
string of
unsigned chars, you cass pass it as char * and cast it inside, that is:
int myfunc (char *str)
{
unsigned char *ustr = (unsigned char *) str;
/* now work with ustr instead of str */
...
}
HTH, kind regards
Bernd
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
I would like to add:
as explained, the types integer and char are incompatibel in Pascal.
Furthermore, char in Pascal is NOT a computational type; you cannot do
arithmetic with chars, and there is no sign with chars (much the same as
in PL/1,
for example). To do arithmetic with chars, you need the conversion
functions ORD and CHR.
This all seems quite natural to me; the C idea that chars are small
integers and therefore have
a sign is strange IMO.
On the other hand, Pascal supports ANY standard or scalar or subrange
type as index type
for arrays, for example:
var howoften : array [char] of integer ;
ch: char;
...
read (ch);
howoften [ch] := howoften [ch] + 1;
the array howoften is used to count the occurence of chars in an input
file, for example.
And: if you want to have small integers (1 byte size), Pascal supports
them, too (with subranges):
type byte = - 128 .. 127;
var x : byte;
if your compiler, supports this, the variable x will use 1 byte and
allow normal integer arithmetic.
Kind regards
Bernd
Am 27.04.2020 um 03:49 schrieb Bernd Oppolzer:
Compare this to Pascal for example, where char and integer are two
different and
incompatible types. To do the same as above in Pascal, you need
conversion functions
(which are part of the Pascal standard):
var c: char;
c := chr (ord ('A') + 1);
c := chr (ord (c) - ord ('A') + ord ('a'));
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Mon, 27 Apr 2020 03:49:00 +0200, Bernd Oppolzer wrote: >First of all, char in C is a subtype of int, >which means that you can do normal arithmetic operations to chars >and that chars are allowed in int expressions without special action >needed. > >for example: > >char c; > >c = 'A' + 1; /* c will be 'B' */ >c = c - 'A' + 'a'; /* c will now be 'b' - lower case */ > Agreed. Yet no such compatibility exists among unsigned char *, signed char *, and char*. However, many implementations quietly ignore violations of this. I encountered this on IBM mainframe when a FOSS program attempted to call a (standard, such as strlen()?) function expecting a char * argument with an unsigned char *. The intrinsic type of "XYZ" here is char *, not unsigned char *, and surely not signed char *. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
First of all, char in C is a subtype of int,
which means that you can do normal arithmetic operations to chars
and that chars are allowed in int expressions without special action
needed.
for example:
char c;
c = 'A' + 1; /* c will be 'B' */
c = c - 'A' + 'a'; /* c will now be 'b' - lower case */
Compare this to Pascal for example, where char and integer are two
different and
incompatible types. To do the same as above in Pascal, you need
conversion functions
(which are part of the Pascal standard):
var c: char;
c := chr (ord ('A') + 1);
c := chr (ord (c) - ord ('A') + ord ('a'));
Back to C:
Now, because chars are small ints in C (much like shorts), they can of
course be signed or unsigned.
If we have 8 bit bytes (which is normal on today's machines, but C would
of course support other
architectures, too), the ranges are -128 .. 127 for signed char (2's
complement) and 0 .. 255 for unsigned char.
If you code
char c;
like in the example above, the char is always signed or unsigned
depending on the default
active during compilation (can probably be modified by compiler option;
if not, there will
be a "factory" setting).
This "factory" setting is unsigned for IBMs z/OS compilers, and signed
for most Windows
and Unix compilers I am aware of.
The reason may be the EBCDIC character set; if signed were used with
EBCDIC, all the
normal characters and digits (X'C1' = 'A', X'F0' = '0') would have
negative char values.
So in my opinion the choice of the unsigned char default is natural for
EBCDIC machines.
The difference between this default has some implications for programs
that want to run
on both platforms (mainframe and PC, for example). I usually cope with
this by explicitly
specifying unsigned char, wherever necessary (only at places, where
computing is done
with character values, for example, when doing hexadecimal output of
storage areas
on both platforms).
BTW: if you want to take a closer look at Pascal, you can find the New
Stanford Pascal Compiler here:
http://bernd-oppolzer.de/job9.htm
https://github.com/StanfordPascal
https://www.facebook.com/StanfordPascal
which runs on IBM Mainframes (MVS and CMS) and on Windows, Unix (Linux),
OS/2, MacOS etc.;
on the Mainframe, 370 machine code is generated. On the other platforms,
the generated P-Code
is interpreted. The P-Code interpreter PCINT is written in C and (of
course) has to use unsigned chars
to implement the P-instructions in exactly the same way as they are
compiled on the mainframe.
Kind regards
Bernd
Am 26.04.2020 um 23:44 schrieb Charles Mills:
Without testing, I think that a signed char argument satisfies and unsigned char
formal parameter, but that &signed char does not satisfy unsigned char *.
There is some C messiness
https://www.facebook.com/StanfordPascal/?eid=ARDEjQaZgVZL2fivkB0AXGk_-mZF97XV3mESzaJ0RR-2NKu0jyroGwFbXt9kqk5UUIUCiHV9d0w2XcfUaround
char signage. I think on most platforms char is kind of the same as signed
char, but not exactly the same. On Z a char is kind of the same as an unsigned
char, but not exactly the same. I am obviously fuzzy on the exact details, and
no doubt someone will be happy to set me straight.
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Actually, on the 3600 you could select whether indexing was 1s' complement or 2' complement. I had lust in my heart for that machine and its big brother, the 3800. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, April 26, 2020 5:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes On Sun, 26 Apr 2020 12:58:57 -0700, Charles Mills wrote: >+1 > >Or RTFKC: >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbclx01/zos_supporting_ansi_iso_standards.htm > Where I read: Equivalent type of char: signed char, unsigned char, or user-defined: The default for char is unsigned My experience, long ago, is that these are distinct types: C/C++ reported a syntax error for formal parameter (char *), actual parameter (unsigned char * ). It's not what it means; it's what it's called. Sequence of white-space characters (excluding the new-line): Any spaces or comments in the source program are interpreted as one space. This may have some contention with historic use of comments as concatenators. E.g. something like writing foo/* */bar for foobar. The result of converting an integer from a shorter signed integer: The lowest 2 bytes of the integer are used to represent the short int. ??? I'd expect sign extension. But wasn't there a transition from unsigned-preserving to value-preserving. E.g.: K&R: -1 > (unsigned) 0 ANSI: -1 < (unsigned) 0 CDC (not IBM) 3600 and earlier 1604 were wretched hybrids. Numeric arithmetic was 1's complement; addressing arithmetic was 2's complement. And CDC 6600 had no compare instruction. FORTRAN compared integers by subtracting (hardware didn't report overflow) and testing the sign of the result. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Without testing, I think that a signed char argument satisfies and unsigned char formal parameter, but that &signed char does not satisfy unsigned char *. There is some C messiness around char signage. I think on most platforms char is kind of the same as signed char, but not exactly the same. On Z a char is kind of the same as an unsigned char, but not exactly the same. I am obviously fuzzy on the exact details, and no doubt someone will be happy to set me straight. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, April 26, 2020 2:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XL C\C ++ sizeof of datatypes On Sun, 26 Apr 2020 12:58:57 -0700, Charles Mills wrote: >+1 > >Or RTFKC: >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbclx01/zos_supporting_ansi_iso_standards.htm > Where I read: Equivalent type of char: signed char, unsigned char, or user-defined: The default for char is unsigned My experience, long ago, is that these are distinct types: C/C++ reported a syntax error for formal parameter (char *), actual parameter (unsigned char * ). It's not what it means; it's what it's called. Sequence of white-space characters (excluding the new-line): Any spaces or comments in the source program are interpreted as one space. This may have some contention with historic use of comments as concatenators. E.g. something like writing foo/* */bar for foobar. The result of converting an integer from a shorter signed integer: The lowest 2 bytes of the integer are used to represent the short int. ??? I'd expect sign extension. But wasn't there a transition from unsigned-preserving to value-preserving. E.g.: K&R: -1 > (unsigned) 0 ANSI: -1 < (unsigned) 0 CDC (not IBM) 3600 and earlier 1604 were wretched hybrids. Numeric arithmetic was 1's complement; addressing arithmetic was 2's complement. And CDC 6600 had no compare instruction. FORTRAN compared integers by subtracting (hardware didn't report overflow) and testing the sign of the result. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Sun, 26 Apr 2020 12:58:57 -0700, Charles Mills wrote: >+1 > >Or RTFKC: >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbclx01/zos_supporting_ansi_iso_standards.htm > Where I read: Equivalent type of char: signed char, unsigned char, or user-defined: The default for char is unsigned My experience, long ago, is that these are distinct types: C/C++ reported a syntax error for formal parameter (char *), actual parameter (unsigned char * ). It's not what it means; it's what it's called. Sequence of white-space characters (excluding the new-line): Any spaces or comments in the source program are interpreted as one space. This may have some contention with historic use of comments as concatenators. E.g. something like writing foo/* */bar for foobar. The result of converting an integer from a shorter signed integer: The lowest 2 bytes of the integer are used to represent the short int. ??? I'd expect sign extension. But wasn't there a transition from unsigned-preserving to value-preserving. E.g.: K&R: -1 > (unsigned) 0 ANSI: -1 < (unsigned) 0 CDC (not IBM) 3600 and earlier 1604 were wretched hybrids. Numeric arithmetic was 1's complement; addressing arithmetic was 2's complement. And CDC 6600 had no compare instruction. FORTRAN compared integers by subtracting (hardware didn't report overflow) and testing the sign of the result. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
In article <006301d61bd2$bf391680$3dab4380$@gmail.com> you wrote: > HI >I am looking in the XL C docs lang reference user guide programming guide > For the length of the following data types > Short , int long and I cannot seem to find it > frustrated > I coded a program > Int len; > Unsigned short shortype; > Int len = sizeof(shorttype); > >But the compiler seemed to comment the above statement > and not generate the assembler ps (I am running metal c); > Any help appreciate it It depends. For 31-bit, it's ILP32, for 64-bit, it's LP64. See: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.cbcpx01/datatypesize64.htm (short is always 2 bytes. SAS/C uses the same scheme.) -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
thanks
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Charles Mills
Sent: Sunday, April 26, 2020 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
+1
Or RTFKC:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
.cbclx01/zos_supporting_ansi_iso_standards.htm
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of retired mainframer
Sent: Sunday, April 26, 2020 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
Don't allow extraneous factors (such as optimization or argument promotions)
to obfuscate the information you want. If you want the sizes of the types,
print the sizes of the types.
#include
int main(void)
{
printf("%zd %zd %zd", sizeof(short), sizeof(int), sizeof(long));
return 0;
}
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Sunday, April 26, 2020 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: XL C\C ++ sizeof of datatypes
>
> HI
>
>I am looking in the XL C docs lang reference user guide programming
guide
> For the length of the following data types
> Short , int long and I cannot seem to find it
> frustrated
>
> I coded a program
>
> Int len;
> Unsigned short shortype;
> Int len = sizeof(shorttype);
>
>But the compiler seemed to comment the above
> statement and not generate the assembler ps (I am running metal c);
>
> Any help appreciate it
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
+1
Or RTFKC:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
.cbclx01/zos_supporting_ansi_iso_standards.htm
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of retired mainframer
Sent: Sunday, April 26, 2020 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
Don't allow extraneous factors (such as optimization or argument promotions)
to obfuscate the information you want. If you want the sizes of the types,
print the sizes of the types.
#include
int main(void)
{
printf("%zd %zd %zd", sizeof(short), sizeof(int), sizeof(long));
return 0;
}
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Sunday, April 26, 2020 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: XL C\C ++ sizeof of datatypes
>
> HI
>
>I am looking in the XL C docs lang reference user guide programming
guide
> For the length of the following data types
> Short , int long and I cannot seem to find it
> frustrated
>
> I coded a program
>
> Int len;
> Unsigned short shortype;
> Int len = sizeof(shorttype);
>
>But the compiler seemed to comment the above statement
> and not generate the assembler ps (I am running metal c);
>
> Any help appreciate it
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
Don't allow extraneous factors (such as optimization or argument promotions)
to obfuscate the information you want. If you want the sizes of the types,
print the sizes of the types.
#include
int main(void)
{
printf("%zd %zd %zd", sizeof(short), sizeof(int), sizeof(long));
return 0;
}
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Joseph Reichman
> Sent: Sunday, April 26, 2020 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: XL C\C ++ sizeof of datatypes
>
> HI
>
>I am looking in the XL C docs lang reference user guide programming
guide
> For the length of the following data types
> Short , int long and I cannot seem to find it
> frustrated
>
> I coded a program
>
> Int len;
> Unsigned short shortype;
> Int len = sizeof(shorttype);
>
>But the compiler seemed to comment the above statement
> and not generate the assembler ps (I am running metal c);
>
> Any help appreciate it
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
The question and the subject do not seem to go together. Shorts are 16 bits; long and long ints are 32 bits on most modern C compilers. As @John says, statements that "don't matter" go away. If you set len and then do not use it, the compiler is free to disregard the setting. Try the volatile attribute and see if that helps. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Sunday, April 26, 2020 6:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XL C\C ++ sizeof of datatypes HI I am looking in the XL C docs lang reference user guide programming guide For the length of the following data types Short , int long and I cannot seem to find it frustrated I coded a program Int len; Unsigned short shortype; Int len = sizeof(shorttype); But the compiler seemed to comment the above statement and not generate the assembler ps (I am running metal c); Any help appreciate it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes compiler bug ?
On Sun, 26 Apr 2020 13:38:49 -0400, Joseph Reichman wrote:
>Tried that great idea however I think you helped me uncover a bug in the
>compiler
>So it seems that a short is 2 bytes look below
>
>However when I passed reclen as a parameter it was by value not by address
>guess what the compiler did
>
> L R14,@...RECLEN
> ST R14,232(R13)
>
>I would of thought it would be STH ?
>
Some of this antedates function prototypes, when the specification was to
widen char and short actual parameters to (long?) int on the stack, and
float to double.
This got me in trouble with Whitesmith compiler when I had such as:
f( char c) {
g( &c );
}
The compiler passed the address of the int it expected on the stack.
Woulda worked on little-endian, where they probably developed and
tested it.
>
> * len = sizeof(reclen);
> LA15,2
> ST15,@111len
>* return len;
> NILH 15,X''
> NILH 15,X''
> BRU @1L38
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes compiler bug ?
Tried that great idea however I think you helped me uncover a bug in the
compiler
So it seems that a short is 2 bytes look below
However when I passed reclen as a parameter it was by value not by address
guess what the compiler did
L R14,@...RECLEN
ST R14,232(R13)
I would of thought it would be STH ?
* len = sizeof(reclen);
LA15,2
ST15,@111len
* return len;
NILH 15,X''
NILH 15,X''
BRU @1L38
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
John McKown
Sent: Sunday, April 26, 2020 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XL C\C ++ sizeof of datatypes
On Sun, Apr 26, 2020 at 8:58 AM Joseph Reichman mailto:reichman...@gmail.com> >
wrote:
> HI
>
>I am looking in the XL C docs lang reference user guide programming
> guide
>
> For the length of the following data types
>
>
>
> Short , int long and I cannot seem to find it
>
>
>
> frustrated
>
>
>
> I coded a program
>
> Int len;
>
> Unsigned short shortype;
>
> Int len = sizeof(shorttype);
>But the compiler seemed to comment the above
> statement and not generate the assembler ps (I am running metal c);
> Any help appreciate it
>
I don't know about about Metal C, but if you use regular C with optimization,
and don't use a variable, the compiler simly won't generate any code to create
or initialize it. Perhaps you could use a program kike:
int main() {
unsigned short shorttype;
int len=sizeof(shorttype);
return len;
}
But, then again, you didn't show us the entire program.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu <mailto:lists...@listserv.ua.edu> with the
> message: INFO IBM-MAIN
>
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu <mailto:lists...@listserv.ua.edu> with the message:
INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XL C\C ++ sizeof of datatypes
On Sun, Apr 26, 2020 at 8:58 AM Joseph Reichman
wrote:
> HI
>
>I am looking in the XL C docs lang reference user guide programming
> guide
>
> For the length of the following data types
>
>
>
> Short , int long and I cannot seem to find it
>
>
>
> frustrated
>
>
>
> I coded a program
>
> Int len;
>
> Unsigned short shortype;
>
> Int len = sizeof(shorttype);
>But the compiler seemed to comment the above statement
> and not generate the assembler ps (I am running metal c);
> Any help appreciate it
>
I don't know about about Metal C, but if you use regular C with
optimization, and don't use a variable, the compiler simly won't generate
any code to create or initialize it. Perhaps you could use a program kike:
int main() {
unsigned short shorttype;
int len=sizeof(shorttype);
return len;
}
But, then again, you didn't show us the entire program.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XL C\C ++ sizeof of datatypes
HI I am looking in the XL C docs lang reference user guide programming guide For the length of the following data types Short , int long and I cannot seem to find it frustrated I coded a program Int len; Unsigned short shortype; Int len = sizeof(shorttype); But the compiler seemed to comment the above statement and not generate the assembler ps (I am running metal c); Any help appreciate it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
