Re: Seeking computer-programming job (Sunnyvale, CA)

[Ben Pfaff]

It must at least partly do so, in order to know what size of thing
*foo is referring to.

No. The ANSI C89 standard says this:

The sizeof operator yields the size (in bytes) of its
operand, which may be an expression or the parenthesized name
of a type. The size is determined from the type of the
operand, which is not itself evaluated. The result is an
integer constant.

C99 has an exception for variable-length arrays.

 

[Series Expansion]

Well, now your incoherence is satisfactorily explained: you are
apparently far too young to have mastered coherence yet.

You see, if somebody is so full of himself [rest of obviously
off-topic post deleted unread]

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, java.oke.

 

[Paul Donnelly]

Kindergarten really has been a great time!!

Well, now your incoherence is satisfactorily explained: you are
apparently far too young to have mastered coherence yet.

You see, if somebody is so full of himself [rest of obviously
off-topic post deleted unread]

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, java.oke.

Since you're impenetrable to rational arguments, I don't see why anyone
would continue to waste time constructing them. Really, they should just
put you in their killfile, like I'm about to do.

 

[MarkH]

Richard Heathfield wrote:

[snip]

Stop attacking me.
.....

Strawman argument.

Do not personally attack me or accuse me of intellectually dishonest
behavior again. You have been warned.
.....

Yes, it's at least partly because there are people who don't know
[rest of personal attacks deleted]

Stop attacking me.

You have a major malfunction "Seamus". Man the hell up, emo boy.

 

[thomas.mertes]

... there are still people who need to write portable C
code, and it is well for them to write C properly and with an eye
to portability.

Portability is exactly the reason I decided to use C to implement
Seed7. When I began to implement the predecessor of Seed7 I used
Pascal but I had much more portability problems with it.

When C compilers use high warning levels it is almost impossible to
write code that never (with no C compiler) gets a warning:

- On some compilers you get warnings complaining about things in
standard include files. How do you get rid of such warnings?
- Historically C had the philosophy that actual float parameters
are automatically converted to double when a function is called.
On some compilers you get warnings when your prototyp requests
a formal float parameter and the actual parameter is a float
also. So you get a warning for something that is 100% OK and
I don't want to cast every float argument to float just to
avoid this warning.
- On some compilers you get warnings when 'unsigned char *' strings
are used for functions like 'strlen' or 'strcpy' (which request
a signed 'char *' pointer). Naturally you can assume that
'strlen' works independent of the sign of the character, but the
compiler warnings do not care about that.
- C has rules how to deal with operations when integers of
different sizes or signedness are involved. One operator argument
is implicitly casted to the type of the other. Naturally such
casts can involve loss of data or loss of the sign. This warnings
are helpful to find possible sources of errors. But to silence
such warnings it is necessary to use explicit casts. The problem
is that with and without explicit casts the same things are done.
The cast just tells the compiler: I know what I mean, just do it.
This way you will not get warnings when new typedefs or other
declarations cause the expression to become dangerous.
- Warnings about 'variablename' may be used uninitialized:
This can be false complaints. Interestingly gcc is not able to
recognize when the states of two variables are connected.
Such as a global fail_flag variable and a local condition
variable (cond). The connection is: As long as fail_flag is
FALSE the cond variable is initialised. When the fail_flag
is TRUE the cond variable is not used and therefore it could
be in an uninitialized state. At several places I use such
connected variable states which are not recognized by the
gcc optimizer and are therefore flagged with a warning. I
accept such warnings in performance critical paths. I am not
willing to do "unnecessary" initialisations in performance
critical paths of the program. At places that are not
performance critical I do some of this "unnecessary"
initialisations just to avoid such warnings.

I appreciate every help to reduce the number of warnings when
compiling Seed7. It would be nice to recive the warnings generated
by various C compilers.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[Guest]

Some warnings, like the one above can be a nuisance.
Another one which is mostly harmless is:

for (cnt=0; cp = fgets(buff, sizeof buff, fp); cnt++) {}

-->> warning: suggest parentheses around assignment used as truth value

Well, there *could* be cases where this warning is wanted.
I don't like excessive parentheses either.

yes but most of us have made the mistake of using = for ==.
I even went though a later phase of using == for =!
I consider that C made a poor choice when selecting these
operators

assignment is :=
equality is =


--
Nick Keighley

"ALGOL 60 was a language so far ahead of its time that it
was not only an improvement on its predecessors but also
on nearly all its successors".
--C.A.R. Hoare

 

[Guest]

Seamus MacRae said:

you'll have to explain that. I prefer warning free code. I'm willing
to
jump through some hoops to achieve it. But it remains a fact that not
all warnings indicate a potential error. If I had a compiler that
issued at lot of spurious warnings for my code I'd seriously
consider such a tool.

If you make comments like that about what seem like fairly sane
development methods then your tend to get remarks like those below:-

 

[Guest]

Richard Heathfield wrote:



It must at least partly do so, in order to know what size of thing *foo
is referring to.

no. Think about it from the compiler's point of view. It actually
has enough information to calculate the value of "sizeof *foo"
without dereferencing foo. It doesn't need to know the value
of foo but only the type of foo. And since it's the compiler
it can simply look up the type of foo in an internal table
and substitute the size of type of foo. Which it also *must*
know since its the compiler (baring incomplete definitions
etc.).

calloc (sizeof *foo);

might well compile to

load R1 #sizeof(struct-tm)
call calloc

where #sizeof(struct-tm) is some sort of internal compiler
directive that in turn expands to something like

load R1 LIT 24

in in a more compact assembler

ld r1 #24


In fact not only is the compiler *able* to do this
but it is *required* to do this. sizeof is not
a function call but an operator

printf ("%ul\n", sizeof (* ((int*)0) ));

won't crash (assuming I got all me brackets right!)



<snip>





--
Nick Keighley

But ye have set at nought all my counsel, and would none of my
reproof:
I also will laugh at your calamity; I will mock when your fear
cometh;
[Proverbs 1:25]

 

[thomas.mertes]

yes but most of us have made the mistake of using = for ==.
I even went though a later phase of using == for =!
I consider that C made a poor choice when selecting these
operators

assignment is :=
equality is =

This is one thing and the other thing is:

The habbit of silently ignoring values.

While it can have an advantage that assignments return
a value it can also have disadvantages. Sure when
assignments just return void some "elegant" code needs
to be written in a longer way, but at least some errors like
the one mentioned above do not happen.

Therefore I prefer assignments without result and no
implicit casts (like a cast to void which just ignores a
value).

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[Seamus MacRae]

You will not escape those "personal attacks" until you stop writing
[rest of threatening and insulting post deleted]

Why are you butting in, and with more off-topic nonsense? Let's get back
to discussing Java and Lisp please.

 

[Seamus MacRae]

No.

Unevaluated, "*foo" is merely a pointer dereference operation. It is not
a value whose size may be measured.

 

[Seamus MacRae]

Ben Pfaff said:

If you look at the grandparent article (my reply, to which Seamus
wrote a reply, to which you wrote a reply), you will find

Very boring. Can we get back to discussing the original topic please?

 

[Seamus MacRae]

Seamus MacRae said:

Richard Heathfield wrote:
[snip]

Stop attacking me.

I invite you to review the discussion once more, to find out who
attacked whom.

It's quite fresh in my memory. I was ambling along, minding my own
business and then making a perfectly innocuous suggestion in a perfectly
civil post when you viciously assaulted me without provocation.

I am less concerned with attacking you than with debunking

I do not need "debunking", thank you very much. Next time, do not
"debunk" unsolicited.

It is *forbidden* to do so

Then how the heck is it supposed to know what size the thing is it's
pointing to?

Regardless, it's been drilled in repeatedly: if "*foo" is encountered
when foo is uninitialized, Bad Things may happen.

You missed my point.

No, I did not. I repeat again: are any of them in widespread use?

You missed my point.

No, I did not. I repeat again: not IEEE754-compatible ones.

Fine, you're entitled to think that

Don't patronize me. You appear to be somewhat of a jerk. Please go look
in a mirror and adjust that attitude you're wearing.

It wasn't a personal attack

Like hell it wasn't. You publicly berated me and implied in front of a
large audience that I was stupid and/or incompetent. What the hell is
the MATTER with you? And with several other people in these newsgroups?

You are taking this far too personally.

That isn't for you to decide.

This is a discussion, not a lawsuit.

It's not a polite discussion, and it hasn't been since you started
making things personal.

You made several nasty errors:
1. You nitpicked a post of mine. Bad move.
2. Then when I responded to smooth things over, you replied with
a more direct and serious attack instead of letting sleeping
dogs lie. Big mistake.
3. You continued to not back down when I continued to try to
reset things to the appropriate state so that the
discussion could move on in other directions.

Don't do that! If you nitpick at something someone said and they respond
in their own defense, leave it at that. You'll have said your opinion,
they'll have said theirs, and everyone can move on. If, instead, you
respond by restating your opinion more forcefully, it starts a fight
instead, and nobody benefits from that.

I described your argument as a strawman argument because

you're an asshole. Yes, yes, I know.

your flawed understanding
led you to believe, mistakenly

Stop personally-attacking me at once. You will not again use the words
"flawed" or "mistaken" to describe me in public. Do I make myself clear?

Leave. Me. Alone.

These newsgroups are for discussing programming, not people. I am
off-topic here.

Spot the (groundless) personal attack, to which I reacted.

There was no personal attack in my post. Saying that environments that
ignore a lot of compiler warnings generate buggy code is not an attack
on any particular person.

Yes, it's at least partly because there are people who don't know
[rest of personal attacks deleted]

Stop attacking me.

For someone who doesn't like personal attacks, you sure like making
them.

No, I do not. Stop publicly lying about me.

I'm already in the right place.

NO. YOU ARE NOT.

You've said your piece. It does not bear repeating.

MOVE ON.

If you seek the truth, it is you who need to move.

Calling me a liar will not make me friendlier.

That is not a personal attack, you buffoon

**** you.

Okay, so I'll retract "buffoon" - but for heaven's sake, lighten up
a little

After you.

and before "correcting" people, take the trouble

to send it as private email rather than a public news post? After you.

 

[Seamus MacRae]

Richard Heathfield wrote:

[snip]

Stop attacking me.

Strawman argument.

Do not personally attack me or accuse me of intellectually dishonest
behavior again. You have been warned.

Yes, it's at least partly because there are people who don't know
[rest of personal attacks deleted]

Stop attacking me.

You have a major malfunction "Seamus".

Who the **** are you, and why is your debut into this thread a personal
attack aimed at a man that has not ever done or said anything to you,
personally, EVER???

 

[Seamus MacRae]

(e-mail address removed) attacked as well:

no.

Yes. See other posts.

It doesn't need to know the value of foo but only the type
of foo.

There are variable-length arrays in C99.

 

[Seamus MacRae]

(e-mail address removed) attacked:

you'll have to explain that. I prefer warning free code. I'm willing
to jump through some hoops to achieve it. But it remains a fact that
not all warnings indicate a potential error. If I had a compiler that
issued at lot of spurious warnings for my code I'd seriously
consider such a tool.

Whereas I'd seriously consider using a different compiler.

If you make comments like that about what seem like fairly sane
development methods then your tend to get remarks like those below

Is that a threat?

Uh-uh. If I make civil, impersonal comments that do not impugn anyone,
directly or indirectly, then I fully expect all responses to be equally
civil. Instead people keep stooping to name-calling when they don't
agree with/don't like what I say. It's like half the people here are
grade-school kids or something. WTF??

[personal attacks by Richard Heathfield deleted]

 

[Ben Bacarisse]

Unevaluated, "*foo" is merely a pointer dereference operation. It is
not a value whose size may be measured.

That's true: it is not a value at all. It is an expression whose
size _can_ be measured.

Since you have rejected the evidence of direct quotes from the C
language standard I don't expect you'll take my word for it. If you
want to go on arguing about what sizeof *foo means I'd like to know
what sources of information you _would_ believe. I.e. where do get your
information from, and what do you consider a definitive source for
resolving questions like this?

 

[Guest]

(e-mail address removed) attacked as well:



Yes. See other posts.

Panto Time! Look out behind you!

Ah, well there is no point in arguing with the man who won't listen.
I merely adress the massed ranks of the Lurkers.

There are variable-length arrays in C99.

yes, you are correct. I tend only to think about C89.
I'm not convinced that variable-length arrays were
a good idea. And even less convinced that sizeof(vararr)
was a good idea.

 

[daniel.eliason]

-see above-


Series Expansion, I think you raise a lot of great issues that I am
learning a lot from!

The thing about GYNSYM, and I confess I am not the one to answer, is
that somehow both the lifetime of the symbol in the symbol table
(internment) and the ability to reference it are _wierd_.

And, I didn't realize it until your post pointed out the issues
surrounding representation! Thanks!

Here's wierd: this works as expected:
----

(eval (let ((c (gensym))) `(progn (setq ,c 'test)(print ,c)(terpri))))

TEST
NIL
----
But this does not work as I expected:
----

(progn (setq #:G1801 'test)(print #:G1801)(terpri))

Error in PROGN [or a callee]: The variable #:G1801 is unbound.
----

I know you can't read and intern a symbol like #:<name>, but somehow
it is done in the context of back-quote processing...

Anybody?

 

[daniel.eliason]

On Jun 1, 12:22 pm, (e-mail address removed) wrote:
-see above-

Now that I think about it, the output of a macro is not text, it is a
parse tree, which then goes straight to the compiler. Same as in my
example, the `() form is never represented as text, it goes to the
EVAL as a parse tree.

For code that comes from the user, it goes through the reader to
become a parse tree, [then macro substitutions], then to the compiler.

So the macro can put in references to symbols, the names of which do
not have valid represetations in user code. I think that partitions
user symbols apart from GENSYM symbols, so that's why GENSYM symbols
used in macros cannot collide with user written code.

Basically...