pre-requestie for learning C...

[Richard Bos]

My assertion would be that I didn't.

My counter-assertion, not would be, but in fact _is_, that by going
against long-established, clear Usenet practise, that is precisely what
you did do.

Richard

 

[CBFalconer]

.... snip ...
<

PS. Chuck, do you have any extra DAC-512s? They look really
cool. Like something from the bridge of Star Trek!

I wish I did. Thirty years ago I found one at Yale, and offered it
to the Computer Museum in Boston. They turned it down!! I was
highly annoyed.

 

[CBFalconer]

(e-mail address removed) (Pascal J. Bourguignon) wrote:
.... snip ...


I hardly think the C standard qualifies as "big"

If you compare the Pascal standard (either ISO 7185 or ISO 10206)
against the C standard, I think you will find the Pascal standards
to be considerably shorter, tauter, and clearer. This is not a
criticism of the C standard, but is caused by the language
complications. ISO 10206 (extended Pascal) is closer to the
capabilities of C. The point is that Pascal was designed as a
whole, while C basically grew.

 

[CBFalconer]

(e-mail address removed) (Ike Naar) wrote:
.... snip ...


Maybe. !! causes an implicit type conversion.

No. ! by itself is a logical operator, and the result is either 0
or 1. !! has no effect on the logical value, but ensures that it
has become either 0 or 1.

 

[Flash Gordon]

Yes. But for any other sort of program other than unix kernel,
C should not be used.

I disagree with that. It is excelent for some of the embedded work I've
done.

And even, for kernel, I'd feel safer if it was
written in Modula-2 or Modula-3 than in C...

Generally I don't care as long as it is properly written.

Did I say so?

Why did you mention comparing big standards and small standards then?

Yes. But it doesn't matter. because you don't program with standards,
but with actual implementations and extensions.

A lot of my programming can be done entirely within standard C, with
specific modules for the non-standard stuff. Even where this is not done
a lot of the lines of code have behaviour entirely specified by the
standard.

The consequence may be that it's harder to port Pascal programs than C
programs, because in a Pascal program you may have to use more
implementation specific extensions.

It's too long since I did Pascal for me to comment.

In my experience, it wasn't true. I've used at least three different
Pascal compilers on MacOS, and had no difficulty in porting programs
from one to the other. At least, not more difficulties than when
porting C programs.

<snip>

If you've only been porting between implementations for the same HW and
OS then you have not done any serious porting. You need to start looking
at systems with different endianness, pointer sizes, integer sizes and
even sometimes different byte sizes!

 

[Pascal J. Bourguignon]

Why did you mention comparing big standards and small standards then?

Because I don't limit the reflexion to C and Pascal.

<snip>

If you've only been porting between implementations for the same HW
and OS then you have not done any serious porting. You need to start
looking at systems with different endianness, pointer sizes, integer
sizes and even sometimes different byte sizes!

Granted.

 

[JosephKK]

JosephKK said:


Nothing that ! doesn't already cause, though. .

It is implementation dependent at best. By the rules, !! converts to
BOOL where ! is the bitwise 1's complement. The bit patterns to
implement BOOL types are implementation defined. There are some
differences in the results depending on what the conversions do and
when they occur in the evaluation of the expression.
.

 

[JosephKK]

You are right, and wrong. They called it EOR.

http://www.atarimax.com/jindroush.atari.org/aopc.html#EOR

I think whoever wrote their assembler had spent too much time in a
Gloomy Place eating Thistles.

Damn, i thought i had used every instruction it had somewhere along
the way.
.

 

[JosephKK]

JosephKK said:


I was tempted to snip that line, but I suspect the obscurity of the
humour would have been too much even for those who are used to me.

Anyway, yes, you're right, but the point is that it's *more*
vulnerable to aggressive quote-n-snip than at least two
alternatives - line prefixes, and quotation marks.


See?

A blessing on Usenet's head.
.

 

[Phil Carmody]

It is implementation dependent at best. By the rules, !! converts to
BOOL where ! is the bitwise 1's complement.

Pick up a book, and learn some C, before throwing nonsense like
that at the group. Well done on achieving such a high error
density, though.

Phil

 

[Keith Thompson]

JosephKK said: [...]

Maybe. !! causes an implicit type conversion.

Nothing that ! doesn't already cause, though. .

It is implementation dependent at best. By the rules, !! converts to
BOOL where ! is the bitwise 1's complement. The bit patterns to
implement BOOL types are implementation defined. There are some
differences in the results depending on what the conversions do and
when they occur in the evaluation of the expression.

That is almost entirely wrong.

The unary ! operator yields a result of type int. Its value is 0 if
its scalar argument is unequal to 0; 1 if the argument is equal to 0.
It does not perform a conversion, and it does not yield a result of
type BOOL, _Bool, or bool, even in C99 which defines the latter two
(unless BOOL is an alias for int). Note that the language (including
the standard library) doesn't define anything called BOOL.

!! is simply two applications of the ! operator. !!x yields 0 if x is
equal to 0, 1 of x is unequal to 0. You can more or less think of it
as a conversion, converting any scalar value to its logical 0-or-1
equivalent, but it's really not a conversion, it's just an expression
that yields a value.

 

[Guest]

Pascal J. Bourguignon wrote:

In my experience, it wasn't true [that pascal was difficult to port].
I've used at least three different Pascal compilers on MacOS, and had
no difficulty in porting programs from one to the other.  At least,
not more difficulties than when
porting C programs.

If you've only been porting between implementations for the same HW
and OS then you have not done any serious porting. You need to start
looking at systems with different endianness, pointer sizes, integer
sizes and even sometimes different byte sizes!

Granted.

You needed some serious black magic in a Pascal compiler for MacOS
(remember Handles?). I think Apple did a lot of their software in
Pascal
so presumably everyone else copied their Pascal extensions.

 

[Pascal J. Bourguignon]

You needed some serious black magic in a Pascal compiler for MacOS
(remember Handles?). I think Apple did a lot of their software in
Pascal
so presumably everyone else copied their Pascal extensions.

Handles are nothing black magic. It's the simpliest thing: a pointer
to a pointer to something. There's nothing new, syntactically or
semantically. It's trivial to implement.

 

[1Z]

Yes. But for any other sort of program other than unix kernel,
C should not be used.

Not even for embedded systems?

 

[JosephKK]

JosephKK said: [...]
Maybe. !! causes an implicit type conversion.

Nothing that ! doesn't already cause, though. .

It is implementation dependent at best. By the rules, !! converts to
BOOL where ! is the bitwise 1's complement. The bit patterns to
implement BOOL types are implementation defined. There are some
differences in the results depending on what the conversions do and
when they occur in the evaluation of the expression.

That is almost entirely wrong.

The unary ! operator yields a result of type int. Its value is 0 if
its scalar argument is unequal to 0; 1 if the argument is equal to 0.
It does not perform a conversion, and it does not yield a result of
type BOOL, _Bool, or bool, even in C99 which defines the latter two
(unless BOOL is an alias for int). Note that the language (including
the standard library) doesn't define anything called BOOL.

!! is simply two applications of the ! operator. !!x yields 0 if x is
equal to 0, 1 of x is unequal to 0. You can more or less think of it
as a conversion, converting any scalar value to its logical 0-or-1
equivalent, but it's really not a conversion, it's just an expression
that yields a value.

Well the very old ANSI draft (pre C90) i have defines the operators as
you say. I used to think i remembered something. I guess not.
8*((

 

[Richard Bos]

Yes. But for any other sort of program other than unix kernel,
C should not be used. And even, for kernel, I'd feel safer if it was
written in Modula-2 or Modula-3 than in C...

It's the way you tell them, really. But the other one does have bells
on.

Richard