Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: I think this is a disadvantag

Reply
Thread Tools

Re: I think this is a disadvantag

 
 
Keith Thompson
Guest
Posts: n/a
 
      06-17-2013
"BartC" <(E-Mail Removed)> writes:
> "Tim Rentsch" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Geoff <(E-Mail Removed)> writes:
>>> FORTRAN didn't need a standard to change it's capitalization
>>> any more than LASER or RADAR need a standard to become laser or
>>> radar. Acronyms such as these succumb to common usage, not
>>> some standardization document that was probably following the
>>> historical usage and not leading it.

>>
>> The difference is laser and radar are not defined by an official
>> standards document. Fortran is (and FORTRAN was). Fortran and
>> FORTRAN are different languages, just as C99 and C90 are different
>> languages.

>
> Isn't Fortran case-insensitive? In that case it would be odd for it to
> matter whether you write Fortran or FORTRAN. A version number should
> be used if it's important to know exactly which revision of the
> language is being discussed.


I'd say the case-insensitivity of the language is irrelevant. The name
of the language needn't follow the rules the language itself imposes on
identifiers.

I agree that a version number -- or, in the case of Fortran and most
other programming languages, a date -- should be specified if it matters
which version your're talking about. I offer no opinion on the Fortran
vs. FORTRAN controversy. (Nor will I offer an opinion regarding Ada
vs. ADA, though in that case I actually have one.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      06-17-2013
Keith Thompson <(E-Mail Removed)> writes:
[...]
> But there is no defined behavior for converting a function pointer
> to an integer (unless you're relying on guarantees outside the C
> standard; I think POSIX defines the behavior).

[...]

I was at least partly mistaken on that point. The result of
converting a function pointer to an integer is implementation-defined
if the result is within the range of the target integer type;
otherwise, the behavior of such a conversion is undefined.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      06-17-2013
On 06/16/2013 09:03 PM, Eric Sosman wrote:
....
> Still, it's a bit startling that you were using original
> FORTRAN (probably not "FORTRAN I") on the 1620. I'd used FORTRAN II
> on that machine a decade before you encountered it, and it's strange
> that you didn't have access to the "more modern" compiler.


I was born the same year as FORTRAN II, so I can understand why that
seems implausible.

I remember reaching the conclusion that I had been taught FORTRAN I at
the time I was preparing my resume for the position that introduced me
to FORTRAN IV. I no longer remember what evidence I based that
conclusion on, except that it involved some text that actually said
"FORTRAN I". This implies that the text must have been written sometime
after the introduction of FORTRAN II; otherwise, it would simply have
said "FORTRAN".

....
> so the restorers would have to fake it with semiconductors. Brought
> back old memories anyhow: Does "4900796" mean anything to you?


No, sorry. At one time I knew a fair amount of the internals of that
machine - it has always been my practice to read user manuals
thoroughly, and there was one available. But it's been a long time, and
that number doesn't trigger any memories for me.
--
James Kuyper
 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      06-17-2013
On Sun, 16 Jun 2013 21:03:21 -0400, Eric Sosman
<(E-Mail Removed)> wrote:

>On 6/16/2013 7:49 PM, James Kuyper wrote:
>> On 06/16/2013 05:20 PM, Eric Sosman wrote:
>>> On 6/16/2013 4:49 PM, James Kuyper wrote:
>>>> [...]
>>>> FORTRAN I (sic) was the very first programming language I learned, in
>>>> high school, around 1976. [...]
>>>
>>> The time line is surprising. In 1966, a full decade earlier,
>>> *my* first programming language was FORTRAN II (which Wikipedia
>>> says had been around since 195, and by 1968 I'd moved on to
>>> FORTRAN IV (genesis 1962).
>>>
>>> What a very backward school you went to, James!

>>
>> Most high schools didn't have computer programming courses at all at
>> that time. The only reason mine did was that an alumnus had donated to
>> the school an IBM 1620 machine that was already long obsolete at the
>> time of the donation. It had no display, just a teletype terminal, and
>> 20KB magnetic core RAM. It had no operating system, a punched card
>> reader, a keypunch machine, and a card sorting machine. It had no
>> built-in capability to perform multiplication - part of the start-up
>> card deck that we had to load into it before compiling and running our
>> programs was a base-10 multiplication table.

>
> A-a-a-a-h, yer takin' me back. Not only was the 1620 unable
>to multiply and divide in circuitry, but it couldn't even add or
>subtract without a table pre-loaded in dedicated memory. Hence
>its nickname of CADET: Can't Add, Doesn't Even Try.


The inability to add was a feature of the 1620 Mod I only. The 1620
Mod II could do addition and subtraction without resorting to a lookup
table. Multiplication still required a table.

> Decimal computer, "Ooh, how primitive." On the other hand, it
>was dead easy to do multiple-precision arithmetic: twenty-digit,
>fifty-digit, hundred-digit numbers, you used the exact same
>instructions as for five-digit quantities. Not bad ...


It also eliminated many of the problems current students have trying
to deal with binary. For that reason I still consider it the best
teaching machine I have seen.

> Still, it's a bit startling that you were using original
>FORTRAN (probably not "FORTRAN I") on the 1620. I'd used FORTRAN II
>on that machine a decade before you encountered it, and it's strange
>that you didn't have access to the "more modern" compiler.
>
> A few years ago I visited the Computer History Museum in its
>new location in Mountain View, California. In a back room they had
>the carcase of a 1620 undergoing restoration -- or "simulation,"
>really, because the core memory had long since turned to dust and
>IBM had informed the museum that the art of making core was lost,
>so the restorers would have to fake it with semiconductors. Brought
>back old memories anyhow: Does "4900796" mean anything to you?


--
Remove del for email
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      06-17-2013
On 6/16/2013 9:31 PM, Keith Thompson wrote:
> Keith Thompson <(E-Mail Removed)> writes:
> [...]
>> But there is no defined behavior for converting a function pointer
>> to an integer (unless you're relying on guarantees outside the C
>> standard; I think POSIX defines the behavior).

> [...]
>
> I was at least partly mistaken on that point. The result of
> converting a function pointer to an integer is implementation-defined
> if the result is within the range of the target integer type;
> otherwise, the behavior of such a conversion is undefined.


... thus presenting a case where the implementation's "definition"
can be "The behavior is undefined." No blurry lines here, nossir!

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-17-2013
Eric Sosman <(E-Mail Removed)> writes:
> On 6/16/2013 9:31 PM, Keith Thompson wrote:
>> Keith Thompson <(E-Mail Removed)> writes:
>> [...]
>>> But there is no defined behavior for converting a function pointer
>>> to an integer (unless you're relying on guarantees outside the C
>>> standard; I think POSIX defines the behavior).

>> [...]
>>
>> I was at least partly mistaken on that point. The result of
>> converting a function pointer to an integer is implementation-defined
>> if the result is within the range of the target integer type;
>> otherwise, the behavior of such a conversion is undefined.

>
> ... thus presenting a case where the implementation's "definition"
> can be "The behavior is undefined." No blurry lines here, nossir!


And no real way to test it at compile time. For object pointers,
you can check for the existence of uintptr_t (#ifdef UINTPTR_MAX),
but there's no such type for function pointers.

I suppose you could do a compile-time test involving the size of the
pointer type and the range of the target integer type (just comparing
the sizes isn't 100% reliable because the target type might have
padding bits). But even then, the implementation-defined result
of the conversion could still be outside the range of the target
type, given a sufficiently perverse implementation. (I think the
DS9K defines the result of converting any function pointer to an
integer type as UINTMAX_MAX+1.)

This could be alleviated by adding optional types, say, uintfptr_t
and intfptr_t to <stdint.h>, guaranteed to hold the result of
converting any function pointer without loss of information.
But I'm not sure it would really be worth the effort.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-19-2013
Eric Sosman <(E-Mail Removed)> writes:

> On 6/16/2013 7:49 PM, James Kuyper wrote:
>> On 06/16/2013 05:20 PM, Eric Sosman wrote:
>>> On 6/16/2013 4:49 PM, James Kuyper wrote:
>>>> [...]
>>>> FORTRAN I (sic) was the very first programming language I learned, in
>>>> high school, around 1976. [...]

> [snip]
>
> Still, it's a bit startling that you were using original
> FORTRAN (probably not "FORTRAN I") on the 1620. I'd used FORTRAN II
> on that machine a decade before you encountered it, and it's strange
> that you didn't have access to the "more modern" compiler.


The 1620 had compilers for both FORTRAN (ie, what is now
called FORTRAN I) and FORTRAN II. However the FORTRAN II
compiler required a configuration with more memory than the
FORTRAN compiler did.

 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-19-2013
James Kuyper <(E-Mail Removed)> writes:

> On 06/16/2013 09:03 PM, Eric Sosman wrote:
> ...
>> Still, it's a bit startling that you were using original
>> FORTRAN (probably not "FORTRAN I") on the 1620. I'd used FORTRAN II
>> on that machine a decade before you encountered it, and it's strange
>> that you didn't have access to the "more modern" compiler.

>
> I was born the same year as FORTRAN II, so I can understand why that
> seems implausible.
>
> I remember reaching the conclusion that I had been taught FORTRAN I at
> the time I was preparing my resume for the position that introduced me
> to FORTRAN IV. I no longer remember what evidence I based that
> conclusion on, except that it involved some text that actually said
> "FORTRAN I". This implies that the text must have been written sometime
> after the introduction of FORTRAN II; otherwise, it would simply have
> said "FORTRAN".


Given that this happened in 1976, a reasonable assumption is that
the text was titled FORTRAN I to distinguish it from even later
FORTRANs. By that time FORTRAN with no suffix generally meant
FORTRAN IV or FORTRAN 66.

As a point of historical information, the IBM language reference
manual for FORTRAN on the 1620 (which was introduced after both
FORTRAN II and FORTRAN III) says simply FORTRAN, not FORTRAN I.
(And the language is definitely FORTRAN I, not FORTRAN II.)
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-20-2013
Keith Thompson <(E-Mail Removed)> writes:

> Keith Thompson <(E-Mail Removed)> writes:
> [...]
>> But there is no defined behavior for converting a function
>> pointer to an integer (unless you're relying on guarantees
>> outside the C standard; I think POSIX defines the behavior).

> [...]
>
> I was at least partly mistaken on that point. The result
> of converting a function pointer to an integer is
> implementation-defined if the result is within the range
> of the target integer type; otherwise, the behavior of
> such a conversion is undefined.


The phrasing here is a little misleading. The result of converting
a function pointer to an integer is always implementation-defined,
ie, the mathematical value is well-defined. If the well-defined
value is not within range of the target integer type then the
conversion operation's /behavior/ is undefined, but that doesn't
change the well-definedness (by the implementation) of the value.
And, because the resulting value is implementation-defined, we can
discover which target types may be used reliably, by reading the
required accompanying definition for what the resulting values will
be.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-20-2013
Eric Sosman <(E-Mail Removed)> writes:

> On 6/16/2013 9:31 PM, Keith Thompson wrote:
>> Keith Thompson <(E-Mail Removed)> writes:
>> [...]
>>> But there is no defined behavior for converting a function pointer
>>> to an integer (unless you're relying on guarantees outside the C
>>> standard; I think POSIX defines the behavior).

>> [...]
>>
>> I was at least partly mistaken on that point. The result of
>> converting a function pointer to an integer is implementation-defined
>> if the result is within the range of the target integer type;
>> otherwise, the behavior of such a conversion is undefined.

>
> ... thus presenting a case where the implementation's "definition"
> can be "The behavior is undefined." No blurry lines here, nossir!


Not blurry at all. The mathematical value is well-defined, by
the implementation. The behavior is defined or not based on the
well-defined mathematical value and the target type in question.
Pretty much like ordinary operations on signed integers.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Who can explain this bug? mathog C Programming 57 06-11-2013 10:09 PM
How do I encode and decode this data to write to a file? cl@isbd.net Python 11 05-01-2013 11:36 PM
Why does this incorrect CRTP static_cast compile? kfrank29.c@gmail.com C++ 2 04-25-2013 01:38 PM
This looks like a Perl bug George Mpouras Perl Misc 18 04-21-2013 11:56 PM
Really throwing this out there - does anyone have a copy of my oldDancer web browser? steven.miale@gmail.com Python 1 04-10-2013 03:32 PM



Advertisments